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Abstract 

Automatic security protocol analysis is currently feasible only for small protocols. 
Since larger protocols quite often are composed of many small protocols, composi- 
tional analysis is an attractive, but non-trivial approach. 

We have developed a framework for compositional analysis of a large class of 
security protocols. The framework is intended to facilitate automatic as well as 
manual verification of large structured security protocols. Our approach is to verify 
properties of component protocols in a multi-protocol environment, then deduce 
properties about the composed protocol. To reduce the complexity of multi-protocol 
verification, we introduce a notion of protocol independence and prove a number of 
theorems that enable analysis of independent component protocols in isolation. 

To illustrate the applicability of our framework to real-world protocols, we study 
a key establishment sequence in WiMAX consisting of three subprotocols. Except 
for a small amount of trivial reasoning, the analysis is done using automatic tools. 
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1 Introduction 



Security protocols are a crucial component of many contemporary applica- 
tions. Their security is however very difficult to assess for humans, mainly 
due to the vast number of attack options available to an adversary. To deal 
with this complexity, a structured approach is needed. Starting from abstract 
protocols, formal methods faciliate the systematic detection of attacks or the 
generation of a proof of correctness. Automating this process in order to min- 
imize the risk of human error is one of the major goals in security protocol 
analysis. 

Automatic protocol verification is, in general, a complex task even for short 
protocols. The time needed for verification of a protocol using modern methods 
employed by state of the art tools such as Scyther [11] or AVISPA [4] is still 
exponential with respect to the number of messages. Consequently, automatic 
verification of large protocols is currently infeasible. In this paper, we attempt 
to narrow the gap between small, academic protocols and large, industrial 
protocols by taking advantage of compositional verification. 

Large protocols are usually built from structured components. They typically 
consist of several (optional) protocols composed in parallel, or a sequential 
composition of a key establishment protocol and a secure data transfer pro- 
tocol that uses the key. For instance, IPSec, SET, and WiMAX have all been 
designed with such a principle in mind. A compositional approach to the de- 
sign and analysis of security protocols is therefore natural and expected to 
reduce the complexity of the analysis of the large protocol to the order of the 
complexity of the analysis of the largest component. This could be achieved 
by first verifying properties of the components in isolation and then using 
the results to deduce properties of the composed protocol. However, as no 
generic compositionality results are known, further assumptions are needed to 
facilitate this type of reasoning. 

We illustrate the non-triviality of protocol composition by means of the well- 
known Needham-Schroeder-Lowe (NSL) public key authentication protocol [33, 
38]. In isolation, it satisfies even the strongest forms of authentication, such as 
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Fig. 1. Repeated NSL protocol: incorrect and correct chaining. 

agreement and synchronization [16]. However, when sequentially composing 
this protocol with itself (see the left drawing in Figure 1), authentication is 
not preserved. The reason is that the initiator i may successfully finish his run 
of the composed protocol, while the responder r possibly never executed the 
second half of the protocol. This is because the second half of the initiator's 
run may match to the first half of a different run of the responder. This au- 
thentication problem is illustrated in Figure 2. Here we see agent A executing 
the initiator role i and agent B executing two different runs of the responder 
role r. The intruder links the messages as indicated. Run A{i) and run B(r)§2 
will agree on the values of ni, and nr, but not on the values of ni' and nr', 
since these last two values are not communicated between these two runs. In 
a similar way, it is clear that run A(i) and run B(r)$l do not agree on the 
supposedly shared nonces. 

This problem is solved in the right drawing in Figure 1 by chaining the two 
protocols. A nonce from the first instance of NSL is repeated as payload in the 
second instance. In this way the two protocols become linked and the chained 
protocol satisfies authentication. The authentication problem from Figure 2 is 
now impossible. 



Even though it is well known that the composition of secure protocols is in gen- 
eral not secure [2,13,26,32] and compositionality has been recognised as one of 
the open challenges for security protocol analysis [12,37], the vast majority of 
formalisms and tools for security protocols have only addressed single-protocol 
(i.e. non-composed) analysis and verification. Early work on identifying and 
addressing the problem includes [20,39]. An initial attempt within the Strand 
Spaces model [42] has led to some theoretical results about compositionality. 
The Strand Spaces approach is similar to the one taken here in that both at- 
tempt to identify the abstract properties two protocols need to satisfy in order 
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Fig. 2. Authentication problem in incorrectly chained NSL protocol. 

to be securely composable. However, this work significantly improves upon the 
Strand Spaces approach in terms of efficiency in verifying composed protocols 
and by considering sequential composition, which was absent in the Strand 
Spaces model. One of the recent significant developments in compositional 
protocol analysis is Protocol Composition Logic (PCL) [17, 18]. It provides 
support for compositional reasoning, and has been applied in a number of 
case studies, including the verification of the TLS and IEEE 802. Hi proto- 
cols [25] and contract signing protocols [5]. While the PCL approach is quite 
general, it cannot, in contrast to the present approach, be easily automated. 

In this paper, we develop a framework to verify security properties of protocols 
that are composed from several smaller protocols. We prove several theorems 
concerning the deduction of properties of a sequential composition of two 
protocols from properties these protocols have when running together in a 
multi-protocol environment. With these theorems, we reduce the analysis of 
a sequential composition to the analysis of the component protocols running 
together. 

Analysing several protocols in a multi-protocol environment is, in general, no 
easier than analysing their sequential composition. In order to make automatic 
analysis feasible, we introduce the notion of protocol set independence, where 
ciphertexts, signatures, and message authentication tags originating in one 
protocol set will never be accepted by the other protocol set and vice versa. 
This notion allows us to prove several theorems regarding the deduction of 
properties of protocols running together in a multi-protocol environment from 
properties these protocols have when running in isolation. 

Verifying independence itself is non-trivial, therefore we need the notion of 
strong independence, where the forms of ciphertexts, message authentication 
tags, and signatures in the two protocol sets are sufficiently different to prevent 
confusion. Strong independence can be easily verified at the syntactical level, 
and implies independence. We show that through common design strategies 
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for security protocols in current use, strong independence will be satisfied. 
Note that different protocols can use the same cryptographic keys and still be 
both, independent and strongly independent. 

The model we use is based on the operational semantics for security proto- 
cols defined in [15]. In contrast to other approaches, in which only singular 
protocols are considered, this model provides a semantics of protocols in a 
multi-protocol setting. This makes it a good starting point for compositional 
verification, since, as indicated, the problem of proving correctness of a com- 
posed protocol can be translated into the problem of proving correctness of 
the components in a multi-protocol setting comprising the components them- 
selves. 

To show the applicability of our work, we perform a case study. We have 
chosen to focus on the IEEE 802.16 standard, also known as WiMAX. This 
standard specifies the air interface of wireless access systems featuring a se- 
curity sublayer intended to protect network operators from theft of service 
and provide confidentiality to subscribers. WiMAX features a security sub- 
layer consisting of several subprotocols for authentication, key management, 
and secure communication. This makes WiMAX well suited for an analysis in 
our framework. Our verification is completely tool-supported, except for some 
trivial reasoning and theorem application. 

Overview of the paper 

We start off by giving a brief description of the security protocol model and 
security properties used in Section 2. In Section 3, we develop a framework 
for compositional reasoning about security protocols, and prove a number of 
compositionality theorems. We show how the developed theory can be ap- 
plied in practice by performing a case study on key management protocols in 
the security sublayer of WiMAX in Section 4. Related work is discussed in 
Section 5, and we draw conclusions and discuss future work in Section 6. 



2 Security Protocols and Their Semantics 

In this section we describe an existing formal framework for modeling security 
protocols, and extend it with notions relevant for compositional reasoning. 

We begin by giving a brief overview of the model in Section 2.1 before de- 
scribing the full technical details in Sections 2.2 and 2.3. The model presented 
here is based on the model defined in [15]. Readers who are familiar with the 
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basic model may skip to Section 2.4 on page 14, as the only change is the 
introduction of parameters for protocols. 

In Sections 2.4 and 2.5 we further extend the model with features not present 
in the basic model defined in [15], namely trace restrictions (similar to pre- 
conditions in PCL and elsewhere), satisfiability predicates, and new security 
notions. 



2. 1 Overview 

The basic entities in our framework are role specifications. Every role specifica- 
tion consists of a sequence of uniquely labeled events describing the messages 
an agent shall send and receive, when it executes the role specification, as 
well as certain security claims. The role specification includes constants which 
roughly correspond to nonces, variables which store values read from the net- 
work, and parameters which represent input. 

A protocol is a collection of role specifications that communicate by send- 
ing and receiving messages. More precisely, a protocol is a partial function, 
mapping role names to role specifications. A run is an execution of a role 
specification by an agent. Communication between runs is asynchronous and 
is modeled by agents reading messages from and writing messages to a shared 
input/output buffer (by executing read and send events). As the buffer is com- 
pletely under the control of the adversary, according to the standard Dolev-Yao 
intruder model, we identify the buffer with the intruder knowledge. The actual 
behavior of the entire system, consisting of the intruder and a set of agents 
executing a number of runs, is encoded in the traces of the system. In some 
situations, we are not interested in all possible traces but in a subset of traces 
that have a certain property; for instance, the subset of traces whose input 
values are secret. In that case, we talk about trace restriction. 

Security properties in our framework are local to a role and are described by 
the claim events in the role specifications. Every claim event in a trace results 
in a statement about the trace that may or may not be true. In this paper, we 
focus on three security properties: secrecy, authentication, and session key es- 
tablishment. A secrecy claim event is essentially the statement that something 
never enters the adversary's knowledge, as determined by the trace. Authenti- 
cation is captured by the notion of synchronization. A synchronization claim 
event translates into the statement that there are runs for the other protocol 
roles in the trace with read and send events that match this run's send and 
read events exactly, both in content and in order. Our notion of session keys 
is that a session key is secret and identifies a protocol session, in the sense 
that there is exactly one execution of every protocol role sharing the session 
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key. 



2.2 Security Protocol Specification 

Let XV be a set of identifiers, TZ a set of role names or roles for short, and 
T a set of (global) functions. There are three types of identifiers: constants, 
variables, and parameters. Constants include the general notion of nonces, and 
we will informally refer to some constants as nonces. Concatenation or tupling 
of terms is written as (x, y) . Encryptions of a term x with a term y are denoted 
by {| x H r Role terms can be considered as templates for messages that are 
read or sent by the agents. The set of role terms is defined as: 

RoleTerm ::= XV \ TZ | T(RoleTerm*) 

| {RoleTerm, RoleTerm) | {] RoleTerm ^RoleTerm 

Terms that have been encrypted with a term, can only be decrypted by its 
inverse term which is either the same term (for symmetric encryption) or the 
inverse key (for asymmetric encryption). We use k~ l to denote the inverse key 
of a key k. In this work, functions from T are only used to construct long-term 
keys, such as pk{r), sk{i), k(x,y). Short term session keys are represented by 
constants. In the remainder of the paper x, y, z range over RoleTerm, and c, d 
over the XV set. 

Example 1. The first message sent by the initiator in the NSL protocol is 
denoted by {] ni, i § p k(r), where ni G XV is a constant, i, r G TZ are role names, 
and pk() G T . 

We say that x\ is a subterm of X2 if x\ □ X2, where □ is the smallest transitive 
relation satisfying the following rules, for all terms Xi,x 2 : 

x 1 Qx 1 , x 1 Q(x 1 ,x 2 ), x 2 Q{x 1 ,x 2 ), x 1 n{x 1 ^ X2 , x 2 Q{x x § X2 . 

For a given set of labels C and a set of claims Claim we define the set of events 
£ as: 

S = ^createi(r) , sender, r', x), reader', r, x), claim^r, c [, x]), endg(r) | 

£ G C,r,r' G 7Z,x G RoleTerm, c G Claim} 

The labels £ extending the events are needed to disambiguate multiple oc- 
currences of an event in protocol specifications (e.g. when composing two in- 
stances of the NSL protocol). A second use of these labels is to express which 
send and read events are supposed to correspond (e.g. in NSL the first message 
sent by the initiator is linked to the first message received by the responder). 
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Event sende(r,r',x) denotes the sending of message x by r, apparently to r'. 
Likewise, reader' ,r,x) denotes the reception of message x by r' , apparently 
sent by r. We interpret role terms of the form -fl u fy v in a send event as en- 
cryption with symmetric or public encryption keys, or signing with private 
signing keys. In a read we interpret it as decryption with symmetric or private 
encryption keys, or verification with public signing keys. An agent can encrypt 
or decrypt a term only when it has the relevant key in its knowledge. Event 
claimi(r,c[,x}) expresses that r upon execution of this event expects the se- 
curity property associated with the claim c to hold with optional argument x. 
A claim event is always local to a role, and does not imply that other roles 
expect the security property associated with the claim c to hold for them. 
Events create^r) and ende(r) are used to signal the start and end of the role. 

Example 2. The first send event of the initiator in the NSL protocol is 
denoted by send^(i, r, {] ni, i |} p fe( r )), where ni G XV is a constant and l\ is 
some label. The first read event of the responder in the NSL protocol is denoted 
by reade 1 (i, r, -fl ni, i fy p k(r)), where ni G XV is a variable. 

A role specification is a pair (elist, type) where elist G £* is a list of events and 
type : XV — > {const, param, variable) is a function that assigns types to the 
identifiers that appear in elist. We require that there is only one create and one 
end in the event list, and that they start and terminate the list. Furthermore, 
we require that the role names in the create and end events are the same, and 
they match the role names that appear in claim events and the sender and 
recipient, respectively, in send and read events. This is the specification's role 
name. The set of all role specifications is denoted by RoleSpec. 

Note that only in the context of a role specification rs can we talk about the 
set of variables or parameters. For a role specification rs = (elist, type), we 
write var rs (x) for the set of identifiers that appear in role term x and are 
considered variables in the role specification. 

A protocol is a partial mapping of role names to role specifications, i.e. 1Z — > 
RoleSpec. We say that r is a role in protocol P if r G dom(P), the domain of 
P. If r is a role in protocol P and £ is a label of an event in the event list of r 
then we write £ G P(r). We extend this notation in the obvious way to £ G P. 
By XV(P) we denote the set of all identifiers that appear in protocol P. The 
universe of protocols is denoted by Prot. 

For a protocol P, we require that all labels are unique, except for the labels 
of corresponding read and send events which have to be identical. For a set of 
protocols II, we require that a label is used in at most one protocol. 

We define a relation -<' on the events of a protocol as the union of the obvious 
event orders on the role specifications. We extend this relation with all pairs 
of identically labeled send and read events so that such send events always 
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precede the corresponding read events. The partial order -< is the transitive 
closure of -<' and represents causality preorder. 

Example 3. The following example specifies the NSU protocol, which is the 
bottom right subprotocol in Figure 1. Notice the parameter nr and the fact 
that ni' is considered a constant by role i, whereas it is a variable for role r. 

NSL'{i) = (createiii) ■ send2(i, r, -fl ni', i, nr § p k( r ))' 

read 3 (r, i, {] ni', nr', r } pk {i)) • send A (i, r, {] nr' } pk ( r )) • end 5 (i), 

{nr i— > param,ni' \— > const, nr' \— > variable}) 
NSL'(r) = (create§(r) • read2(i,r, -fl ni',i,nr fy p k( r ))' 

sender, i, { ni', nr', r $ pk (i)) • read A (i, r, {] nr' }pfc( r )) • end 7 (r), 

{nr i— > param,ni' \— > variable, nr' \— > const}) 

^.5 i?nns and Traces 

In this section we describe how, through instantiation, an abstract role spec- 
ification can be transformed into an execution of a role, which we call a run. 
Furthermore, we define how the interleaved operation of a collection of runs 
defines the traces of a system. 

i?un terms model the actual messages sent in a protocol. Since the run terms 
are instantiations of role terms they are defined similarly. Let Runid be a set 
of run identifiers, IT a set of intruder- generated run terms and A a set of 
agent names which is a disjoint union of a set of trusted and a set of untrusted 
agents, At and Au respectively. The set of run terms is defined as: 

RunTerm ::= A \ T [RunTerm*) \ XT)%Runid \ XT \ 

[RunTerm, RunTerm) \ {| RunTerm ^RunTerm 

The run terms of the form TV^Runid and the terms in XT are called nonce 
run terms. The subterm relation □ on run terms is defined similarly to the 
subterm relation on role terms. Since it is clear from the context which one is 
used, we allow the same notation for both relations. In the remainder of the 
paper t, u, v range over RunTerm. 

A role term is turned into a run term when abstract role names are replaced 
by concrete agent names, and constants are made unique by extending them 
with a run identifier. This is done by means of an instantiation, which is a 
triplet (rid,p,a), where rid G Runid, p is a partial function from role names 
to agent names, and a is a partial function from identifiers to run terms. We 
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denote the set of all possible instantiations by Inst. 

In the context of some role specification rs with type function type, an instan- 
tiation inst = (rid, p, a) turns a role term x into a run term, if p is defined 
for every role name that appears in x and var rs (x) C dom(a). For any f <E J 7 
and role terms x±, . . . ,x n G RoleTerm, instantiation is defined recursively by: 

p(r) if x = r G 7£ 

cjjrirf if x = c G Z£> A type(c) = const 

a(x) if x G XT' A type(x) G {param, variable} 

f(mst(xi), inst(x n )) if x = /(xi, . . . , x n ) 

(inst(xi), inst(x 2 )) if x = (x 1; x 2 ) 

H inst(xi) }inst(x 2 ) if x = {| xi } X2 

If an instantiation cannot be applied because var rs (x) G\ dom(a), we say that 
x has free variables in this context. 

Example 4. If we apply instantiation (42, {? i— > a,r i— > 6}, {ni i— > m(}41}) 
to the contents of the first send event of the responder in the NSL protocol 

{ ni, nr, r $ pk(i) , we obtain { mj}41, nr JJ42, 6 |} pfc(a ), 

Instantiations are essential ingredients to define the notion of a run of a role. A 
run of a role specification rs = (elist, type) is a pair (inst, elist'), where inst G 
Inst and e/zst' is a suffix of e/ist. In this definition we express that one is mainly 
interested in the current state of an agent executing a role. We model this 
dynamic aspect by requiring that the list elist' G S* contains the remaining 
events in the role specification, and not the complete role specification. The 
instantiation inst contains the actual values of the variables and parameters, 
as well as the agent names expected to execute the other protocol roles. The 
set of all runs is denoted by Runs. A run event is a pair (inst, ev) G Inst x S. 
These are the events that can be observed when executing a system. A system's 
behavior is represented by a sequence of run events, which we call a trace. The 
universe of traces is denoted by Traces. 

Let P be a protocol with a role specification rs = (elist, type), and let inst = 
(rid, p, a) be an instantiation. The pair (inst, elist) is an initial run for rs if 
and only if dom(p) = dom(P) and dom(a) = type^ 1 (param) (a is defined for 
all role parameters, specifying the run's input). The set of all initial runs for 
all roles of a protocol P is denoted by runsof(P). For a protocol set II, we let 

runsof(U) = [J runsof(P). 
Pen 

Example 5. An initial run of the initiator of the NSL 1 protocol from Exam- 



inst(x) = < 
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pie 3 is ((42, {i i— > a,r i— > 6}, {nr i— > m(J41, w' i— > -L}), create\(i\ 
send 2 (i, r, { ni', i, nr ^ pk ( r ))- read 3 (r, i, { ni', nr' , r $ pk (i))- send 4 (i, r, { nr' ^ pk ( r ))- 
end 5(1)). Notice that nr is the only parameter (and thus must be initialized), 
that variable nr' has no initial value and that ni' is a constant. 

For a protocol set II we consider a system with a number of runs (communicat- 
ing with each other) executed by agents in presence of an intruder. We assume 
a standard Dolev-Yao model, in which the intruder has complete control over 
the communication network. The knowledge of the intruder, denoted by M, 
is a subset of run terms. He can decrypt messages if he knows the appropriate 
decryption key, and he can construct messages from his knowledge set. We 
express this by requiring that M is closed, that is: 

V u ,veM(u, v) e M =>■ {u} v e M 

Vu,v(u, v) e M u,v e M 

The closure M of a set of run terms M is the smallest closed superset of M. 

Due to the dynamic behavior of the system, the intruder knowledge increases 
during the execution. We assume that the initial knowledge M of the intruder 
can be derived from the protocol and the context (e.g. the public keys of 
all agents and the secret keys of all compromised agents). We require that 
XT C Mo. The derivation of the initial intruder knowledge from the protocol 
specification is treated in detail in [14]. 

The behavior of the system is defined as a transition relation between system 
states. Every state is determined by an intruder knowledge set M containing 
run terms (which is also used to model an asynchronous communication be- 
tween agents), and a set F containing all active runs. We denote by runids(F) 
the set of all run identifiers that appear in F. Every transition is labeled with 
a run event (inst, ev) e Inst x £ . 

The derivation rules for the system are given in Table 1. We denote by F[x/y] 
the set obtained from F when x replaces y. Note that from run events used to 
label transitions, one can uniquely determine role specifications. All instantia- 
tions that appear in a rule are applied in the context of this role specification. 

The create rule expresses that a new run can only be created if its run identifier 
has not been used yet. The end and claim rules express that these events can 
always be executed. Recall that M denotes the closure of the set M. The send 
rule states that if a run executes a send event, the sent message (obtained by 
instantiating a role term in the role specification context determined by the 
run event) is added to the intruder knowledge and the executing run proceeds 
to the next event. 
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The read rule determines when a read event can be executed, with the help 
of a match predicate defined as follows: 



Match(inst, m, t, inst') •<=>- inst = (rid, p, a) A inst' = (rid, p, a') A a C a' A 

dom(a') = dom(a) U var rs (m) A inst'(m) = t. 

The match predicate decides if an incoming message t can be matched against 
a pattern specified by a role term m. With respect to the first instantiation 
inst, the pattern may contain free variables. The idea is that the second in- 
stantiation inst' extends the first instantiation by assigning values to the free 
variables such that the incoming message equals the instantiated role term. 
Note that the run event determines role specification rs. 

Example 6. We have Match(inst,m,t,inst') for inst = (42, {i i— > a, r t— > 
b},{nr ^ !_}), m = {] ni, nr, r } pk (i), t = {] m(|42, nrJJ12, b § pk (a), and inst' = 
(42, {i i— > a, r i— > 6}, {nr i— > nr(jl2}). This models the first receive event of 
agent a executing the initiator role of NSL in run 42. The symbol _L means 
that no value is assigned. 

A state transition is the conclusion of an application of one of these rules. In 
this way, starting from the initial state So = (Mo,0), where Mq refers to the 
initial intruder knowledge, we can derive all possible behaviors of a system 
executing a protocol set II. 

run = (inst, createi(r) • elist) € runsof (IV), inst = (rid, p, a), rid runids(F) 
create _ ^ {mst ^ tee{r)) — - - — — — — 



run = (inst, end(r)) £ F. 

[end] 



(M,F) ^^M) (M,F[(inst,e)/run]) 



run = (inst, sendc(m) ■ elist) E F 

[send] 



[read] 



(M, F) (ms *' s !!f * (m)) U {inst(m)}, F[(inst, elist) /run}) 

run = (inst, readi(m) ■ elist) G F, t € M, Match(inst, m, t, inst') 
(M,F) ^ nst '^ d ^ (M,F[(inst>, elist) /run]) 



r , . i run = (inst, claim e(r,c[,x]) • elist) € F 

(M,F) ^^r,c M )) {M ,F[(znst,eUst)/run]) 



Table 1 

Derivation rules. 
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We define the set of traces generated by the above derivation rules as a subset 
of Traces. Let a G Traces be a trace of length \a\ — n, and denote by ctj the 
ith run event in a (starting with 0). Then a is a valid trace for the system 
if there exist states Si,S 2 ,...,S„ such that £ ^ Si — > • • • S n is a 
valid derivation. We denote the set of all valid traces for the protocol set II 
by Tr (II). When we consider the trace set Tr({P} U II) we say that P runs 
in the context of II. 



We reconstruct state information from a trace as follows. If ctj is a run event 
from trace a, then Mf is the intruder knowledge component M of the state 
right before the execution of CKj. Thus for all protocols P and traces a G Tr(P), 



Next, we define a useful short hand. Let IT be a protocol set with P G II, 
and let a G Tr(U). A cast for P in a is a map cast : dom(P) — > Runid 
such that for some fixed p, for every role r G dom(P) there is a run event 
ccj = ((cast(r), p, •), createg(r)) with I & P. Intuitively, for a trace a, a cast is 
an assignment of runs to roles, which expresses the possibility that these runs 
together form a session of the protocol. We denote the set of casts for P and 
a by Cast(P, a). 



Example 7. We illustrate the concept of a trace by providing, in Figure 3, 
a possible trace of the NSL' protocol from Example 3. This trace consists 
of the execution of three runs. The first run is an instantiation of role i, 
with instantiation (1, {i i— > a,r i— > b}, {nr i— > u,nr' i— > J-}), where a and 6 are 
agents, w is a nonce run term, and _L means that no value has been assigned yet. 
The second run instantiates role % as (2, {% \— > a, r \— > b}, {nr \— > f , nr' i— > _L}), 
for nonce run term v ^ u. The third run is an instantiation of the responder 
role r, through (3, {i i— > a, r i— > 6}, {nr i— > -u, m' i— > -L}). Since runs 1 and 
3 are instantiated such that they correspond, they can be executed up to 
completion. In contrast, run 2 is blocked. 

After execution of this trace the intruder knowledge M is extended with the 
information contained in the four send events from the trace. Thus we have 
that M is equal to: 



M U {fl m'fJ2, i, v } pfc(r ), {| m'(}l, i, u } pfc(r ), {] m't}l, nr'(}3, r } pfc(i ), { nr'fj3 } P k( r )} 

There are two casts for the NSU protocol in this trace: {i i— > 1, r t— > 3} and 
{i i— > 2, r i— > 3}. 
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Fig. 3. Example trace of the NSV protocol (p = {i t— ► o, r i-> 6}). 



2.^ Trace restrictions 

In Sections 2.2 and 2.3 we have described the semantics proposed by Cremers 
and Mauw in [15]. In this and the next section we define mechanisms for 
properly handling parameters, and we add several new security properties to 
the semantics, both important for protocol composition. 

Note that there are essentially no restrictions on which values parameters take 
in the semantics. We interpret parameters as input to the protocols, and as 
such we need to specify where the protocol gets its input from. We do this on 
the level of protocol sets by specifying which protocols produce output and 
which protocols are allowed to use this output as input. This specification is 
done by means of trace restrictions. 

When we study protocols in isolation, we do not want to consider how the input 
is created, we only want to consider what properties hold for the input. We 
model these properties using trace restrictions. While some trace restrictions 
are related or similar to security properties, trace restrictions do not model 
protocol security properties, but rather usage of the protocols. 

A trace restriction is essentially a predicate on a trace set. We use this predi- 
cate as a filter, selecting a subset of the trace set. 
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Definition 8. Let IT be a protocol set, and let x be a predicate on Tr(U). 
Then 

Tr(Tl;x) = {ae Tr(U) \ X (a)}. 

In practice, a user first executing a protocol P and then executing a second 
protocol Q might pass values obtained from P as input to the execution of Q. 
In a trace, the mechanism for passing the input value is encoded by initializing 
the parameter for the Q-run of an agent in some role, to a value produced by 
the P-run of the same agent acting in the same role. 

There are two variants to this use. Either the user inputs a value generated by 
P into one or more executions of the same role of Q, or he inputs a value into 
just one execution of the Q role. We define two trace restrictions corresponding 
to these uses, labeled 10 and IO\. 

We say that a protocol P establishes an identifier c if for any trace a and 
every occurrence of events (inst, end^r)), £ G P, in the trace, inst is defined 
at c. This condition can be verified by a syntactical analysis. 

For the remainder of this section, let II be a protocol set, let II' C II be a set 
where every protocol establishes c, and let II" C II be a protocol set where 
every protocol has d as a parameter in every role. Let a G 7r(n), and let I 
contain all subscripts of events in a which correspond to a create event from 
11": 

I = {i \ cti = {insti, create A t G II"}. 
For each i <E I, define the sets 

M = {j | OLj = (instj, create i{r-j)) A t G II" A instj(d) = insti(d)} and 
Bi = {j | ctj = (instj, endnij-i)) A t G II' A instj(c) = insti(d)}. 

The set contains the runs that received the same input as the run that was 
started in ai, and Bi contains the set of runs that could have produced this 
input. We also define the following subsets: 

A[ = {j G Ai | Vr G 1Z : instj(r) = mstj(r)} and 
B[ = { j G Bi | Vr G 1Z : instj(r) = insti(r)}, 

where the equality is in the sense that either both are defined and equal, or 
both are undefined. The set A' { is therefore the subset of Ai of which the runs 
have the same p as ctj, that is, they believe they are communicating with the 
same partners. The set B[ has a similar interpretation. 

Definition 9. Let IT ^ 0, II" be such that all protocols in IT U IT have the 
same role set. We define the predicates 

Xio(os] IT', n", c,d)^VieI 3j G B[ Wk G A\ : j < k 
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and 



Xioi(a;W,U",c,d) 

Vt G / 1/ •//;:/ injective A (Vj G 4 : f(j) < j). 

The trace restriction xio(oe; n', II", c, d) says that a protocol set II" takes its 
input from a protocol set IT. As explained before, this means that any run of a 
role of a protocol in II" initializes its input parameter d to a value that has been 
recorded in c earlier in the trace, in a run of the corresponding role of a protocol 
in IT. (The initialization is specified by defining a only at the input parameters 
when the run is created.) In the stricter trace restriction, Xioi( a ', n', II", c, d) 
it is required that at most one run of a role of a protocol in II" can take as its 
input a value produced in a run of the corresponding role of a protocol in IT. 
In order to ease notation, when II = Hi U n 2 , IT' is a subset of IT and Q G n 2 , 
instead of writing Tr(U; X/o(s n', Q, c, d)) and Tr(U; Xio\{'\ H', Q, c, d)), we 
simply write 7V(IIi(c) LHI 2 (c/d)) and JV(IIi(c) LHI 2 (c!/d)j respectively. 

Our main goal is to study security properties of component protocols in iso- 
lation. When one protocol takes input from another protocol, we do not want 
to include the second protocol in the analysis. Our strategy is instead to spec- 
ify preconditions on the input to our protocol, sufficient for the protocol to 
achieve its goals. We express these preconditions in terms of trace restrictions. 

Next, we define what it means for input to be secret. We emphasize that 
the trace restriction makes no claim about what eventually happens with the 
input. It may very well not remain secret. But the construction is such that it is 
possible to keep the input secret. As an example, consider the empty protocol 
with a claim for secrecy of the input identifier. Under a secret trace restriction 
on the input, the secrecy claim should always be satisfied. To achieve this, we 
resort to a technical trick. The idea is that since d is a parameter in the run 
with run identifier rid, the run term d%rid is guaranteed by the semantics not 
to be known by the adversary or any other execution at the start of the run. 
Note that d%rid should not be thought of as a locally generated nonce, it is 
merely a convenient name for something generated elsewhere. 

Definition 10. We define the predicate 

Xsecret(&] II", d) V? G / : j = min Aj A instj = (rid, -, •) =^ inst^d) = d%rid. 

A somewhat stronger notion of secrecy is that of session key, where we not 
only have secrecy, but also a notion of a session. 

Definition 11. Let the event ctj have instantiation insti, label and role r iy 
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with £i G Pi. We define the predicate 

Xsession (<-^j II , (£) "vv - 

Vi G / : (3j G : inst,- = (rid, •, •) A insti(d) = dtyrid) A 
(3/ : -> ft : / injective A 

Vj G 4 : ^ G Pi A ./I/) = r,-) 

Finally, a much simpler concept is that the protocol takes its input from the 
adversary. In this case, the idea is that the protocol does not really care about 
where its input comes from, just that it gets its input. We do not believe this 
is interesting on its own, but it is a useful tool in analysis. One such example is 
protocols where the chaining nonce is public, for instance NSL variants using 
signatures instead of public key encryption. 

Definition 12. We define the predicate 

X adversary (o! , hi , G?) "vv - 

VI < % < \a\ : on = (inst, create e (r)) A t G II' =>- inst(d) G M". 

To simplify the notation, we denote these trace sets simply as Tr (II {secret / d)) , 
Tr(U(session/ d)) and Tr(U(adversary/d)). 

2. 5 Security properties 

We have already introduced claim events in the trace model. Claim events 
are not real protocol events, but markers we put in a trace to indicate that 
a certain statement about the trace is supposed to hold. We can, for in- 
stance, extend the role definition of NSL'(i) from Example 3 with claim event 
claim$(i, secret, ni'), which contains the claim secret. If an agent reaches this 
claim event during his execution of role i, it is intended that an intruder will 
never learn the value of his nonce. 

The definition of security properties proceeds in three steps. First, we define 
the general signature of a security property, which we consider a predicate on 
protocol traces. Next, we express that such a property is satisfied if it holds for 
all traces of the protocol. Finally, we define a number of security properties, 
such as secrecy and authentication. 

In general, a security property is a predicate on the traces of a protocol. So, 
given protocol II and a claim cl, f c i(U, claime(r,cl,m)) assigns truth values 
to pairs (inst, a), where a is a trace of II and inst is an instantiation of the 
variables in the claim event. 
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Definition 13. A security property is a function fd, cl G Claim, that asso- 
ciates with every pair (IT, ev) of a protocol set II and a role claim event ev 
with claim cl, a predicate on pairs of instantiations and traces: 

fd : V(Prot) x {claim t{r,cl,m) \ £ G C,r G lZ,m G RoleTerm} — > 

U {/nsi x Tr(n) -> {*rue,/afee}}, 
nePCProt) 

where V(Prot) is the powerset of the set of all protocols. 

Note that a context is needed to evaluate an instantiation, and the label £ on 
the role claim event determines this context. 

A security property f c i is satisfied in protocol set II if it yields true for all 
protocol traces containing this claim cl. This is expressed in the following def- 
inition. However, we have included the additional restriction that only claims 
concerning sessions between trusted agents are evaluated. One cannot expect, 
for instance, that a shared secret is really secret if one of the communication 
partners is corrupted. Notice that this does not rule out the possibility that 
a secret in a trusted session is broken due to an interleaving of a session with 
untrusted partners. Of course there are security properties for which this re- 
striction is not appropriate, but since the properties used in this paper all 
have this restriction in common, it is included in the following definition of 
satisfaction. 

Definition 14. Let f d be a security property, II a protocol set, and £ the label 
of a claim event with claim cl. We say that II satisfies the claim £, denoted 
by sat(II,£), if 

Va G Tr(n)Vi : ctj = (inst, claim e(r,cl,m)) =>- 

/d(n, claime(r, cl, m))(inst, a) V (inst = (•, p, •) A im(p) % At). 

We extend this in the obvious way with trace restrictions and to sets of claim 
event labels writing sat (II, {£i}; x)- 

As an example, we can claim secrecy for a particular role term m by inserting 
a suitable claim event into the protocol specification. That claim event will 
translate into the following statement about a trace a: The adversary never 
learns the run term inst(m) in the trace a. 

Definition 15. Let a G Tr (II). The security property f secret associates the 
protocol set II and the claim event ev = claim^r, secret, m) with the statement 

/ secrei (II, ev)(inst, a) <^> inst{m) g M^ +1 , 

where the initial intruder knowledge is determined from IT. 
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We also need to express that a given run is part of a session for its protocol. 
We achieve this by requiring that no two runs of the same role of the protocol 
have the same value for the session identifier (the argument). We call this 
property session uniqueness. 

Definition 16. The security property f session-unique associates the protocol set 
n and the claim event ev = daimnir, session-unique, m) with the statement 

fsession-unique{n, ev)(inst, Oi) "vv- VI <J i-,3 — 1^1 • 

{oii = (insti, claime(r, •, •)) A 
cej = (instj, claim z(r, •, •)) A 
instiim) = instj (m) = inst(m)) =>- i = j. 

Many protocols establish session keys, and we identify three requirements that 
a session key needs to satisfy: 

(1) The session key must be secret. 

(2) There must be a session, that is, one run of each role of the protocol must 
know the session key. 

(3) The key must act as a session identifier, that is, it must be unique across 
all runs of the same role of the same protocol. 

The first requirement is taken care of by the secrecy property and the third 
requirement by the session-unique property. The second requirement is taken 
care of by data agreement for the session key, which we now define. The idea 
is that, for every other role in the protocol, there must exist a run that has the 
same value for the term at some event causally preceding the claiming event. 
These runs must also agree on which agent executes which role, thus possibly 
forming a session of the protocol. 

Definition 17. The security property f data-agree associates the protocol set 
II and the claim event ev = claim^r, data- agree, m), with t G P with the 
statement 

f data-agreed ev)(inst, a) 3cast G Cast(P,Ot) \ 

Vr' G dom(P) 3j : ctj = (instj, •) A 

instj = (cast(r'), •, •) A instj (m) = inst(m). 

Note that causal precedence is implicitly required in this definition. Given any 
trace with a claim event, we can create a new trace by removing any event not 
causally preceding the claim event. Hence, for the definition to be satisfied, 
there must be agreeing events for all roles causally preceding the claim event. 

Now we can define the session key claim. 
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Definition 18. The security property f session associates the protocol set IT 
and the claim event ev = claim^r, session, m) with the statement 

f session (U,ev)(inst,a) 

/ secrei (Il, claime(r, secret, m))(inst, a) A 

f session-unique^-, claim e (r, session-unique,m)){inst, a) A 

f data-agree (n, claim e (r, data- agree, m)) (in st, a) . 

We also define a weaker session key claim, where we drop the requirement 
about the agreement with (and therefore existence of) communication part- 
ners. 

Definition 19. The security property f wse ssion associates the protocol set II 
and the claim event ev = daintier, wsession,m) with the statement 

fwsession (II; GV)(inst, Ol) "vv - 

/ secrei (n, claimiir, secret, m))(inst, a) A 

/session- unique 0^-, claim e (r, session-unique, m))(inst, a). 

Finally, we deal with authentication. Our preferred notion is synchroniza- 
tion [16], a strong form of authentication. A non-injective synchronization 
claim holds if there are executions of the other protocol roles whose read and 
send events match the claiming execution's events, up to the claim event. An 
even stronger notion of authentication, injective synchronization, holds if there 
is exactly one set of executions of the other protocol roles such that the read 
and send events match the claiming execution's events, up to the claim event. 

Definition 20. The security property f syn ch associates the protocol set II 
and the claim event ev = claimiir, synch), £ G P for some P G II with the 
statement 

fsynchijl, ev)(inst, a) <^ 3cast G Cast(P, a), 1 < i < \a\ : a; t = (inst, ev) A 
Vr' G dom(P)W G P{r) : £' G P(r') A read fJ -< ev A 
=>• 3 j < k < i : 
otj = (inst" , sende'(m)) A ak = (inst'" , read^(m')) A 
inst"(m) = inst"'(m') A 

((inst" = (cast(r), -, ■) A inst'" = (cast(r'), ■, ■)) V 
(inst" = (cast(r'), ■, ■) A inst'" = (cast(r), ■, ■))). 

Definition 21. The security property fi- sy nch associates the protocol set II 
and the claim event ev = claim e (r, i-synch), £ G P for some P G II with the 
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statement 

fisynch(N-, ev)(inst, a) 3\cast G Cast (P, a), 1 < i < \a\ : a.i — (inst,ev) A 

Vr' G dom(P)W G P{r) : £' G P(r') A read*/ -< ev A 
=>• 3 j < k < i : 
otj = (inst", sende'(m)) Aat = (inst'", reaaV(m')) A 
inst"(m) = inst"'{m') A 

((inst" = (cast(r), ■, •) A mst w = (cast(r'), •, •)) V 
(inst" = (cast(r'), •, •) A mst'" = (cast(r), •, •))). 



Certain security properties can be evaluated by merely looking at the events in 
a trace that belong to the protocol in which the claim was made. This class of 
properties are called protocol-centric, and as we will see, we can prove theorems 
that apply to all properties in this class. Since authentication properties are 
concerned with the occurrence of events of the given protocol, they are typical 
members of this class. 

Definition 22. Let P be a protocol, and II a protocol set. Denote by Tip and 
7Tn the maps on traces that remove any protocol event that does not belong 
to P or a protocol in II, respectively. 

Let s be any bijection on the set of nonce run terms {cftrid \ c G XV, rid G 
Runid} U XT. This is basically a renaming of nonce run terms. Any such 
bijection can be naturally extended to a bijection on the set of run terms. For 
any trace a, we define s(a) to be the trace where every instantiation inst is 
replaced with s o inst. 

Definition 23. We say that a security property j c \ is protocol- centric if for 
any (II, ev) such that fa is defined and ev belongs to a protocol P G II, and 
for any renaming s on nonce run terms, 

Va, a'Vinst G Inst : s(iTp(a)) = irp(a') 

=>• f d (U, ev)(inst, a) = f d (U, ev)(s o inst, a'). 



(The renaming s is included in this definition for technical reasons.) 

We observe that session-unique, data-agree, synch and i-synch are protocol- 
centric, while secret and therefore session are not. 
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3 Framework for reasoning 



Automatically proving large protocols secure is computationally challenging. 
If the protocol can be split into a sequential composition of several subproto- 
cols, one approach to verification is to analyze the subprotocols in a common 
context. Properties proved for each of the subprotocols running in this multi- 
protocol context can often be used to deduce properties for the composed pro- 
tocol. Note that some authors consider protocols running in a multi-protocol 
context to be composed in parallel. We use "composition" only about opera- 
tions that combine two or more protocol objects into a new protocol object. 
The only form of composition considered in this paper is sequential composi- 
tion. 

Unfortunately, automatically verifying protocol properties in such a multi- 
protocol context is not computationally easier than analysing the composed 
protocol itself. The ideal is to study each subprotocol in perfect isolation, 
without consideration of any other protocols. Our approach is to study under 
which conditions protocols running in parallel can be shown not to interfere 
with each other, such that results obtained by analysis in isolation will be 
valid for a multi-protocol context. 

Our approach is to use a very strong, but efficiently verifiable notion of in- 
dependence between protocols. We show how to design protocols to ensure 
such independence without incurring any significant performance penalty. We 
then prove a number of theorems showing conditions under which protocols 
can run in a multi-protocol context without interfering with each other. Fi- 
nally, we define sequential protocol composition (similar to the one in PCL) 
and show how properties of subprotocols can be combined to give security 
properties for the composed protocols. 

We use the formal model described in Section 2, with two restrictions: 

(1) We require that the partial function a in instantiations assigns only nonce 
run terms to variables and parameters. 

(2) We restrict ourselves to protocols that use secret long-term keys only as 
keys, never as content of messages. 

The first restriction is essential for the notion of strong independence, defined 
in the next section. We refer to Section 6 for a discussion of the implications. 
The second restriction could be lifted, but this would subtly complicate anal- 
ysis, since the use of long-term secret keys becomes much harder to predict. 
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3. 1 Independence 



We say that two protocols are independent if no encryption term produced 
by the first protocol running in the context of the second protocol will be 
decrypted or verified by the second protocol, and vice versa. Formally: 

Definition 24. Let ni,n 2 be two disjoint protocol sets, and let x be a (pos- 
sibly empty) trace restriction. We say that fix and Yi 2 are independent in the 
context of x, denoted indep(Il 1 , n 2 ; x) (alternatively if x is empty, Hi and Yi 2 
are independent, denoted indep(n 1 , n 2 )), if 



an = (inst, sende(m)) A (ctj = (inst', reade>(m')) V ctj = (inst', sendi>(m')) V 



In general, proving independence is a non-trivial problem, but for many pro- 
tocol sets it is easy in the sense that the protocol sets satisfy an even stronger 
notion of independence. We say that two protocol sets are strongly indepen- 
dent if they have no encryptions of the same form. Unlike independence, strong 
independence can be easily verified at the syntactical level, and it implies in- 
dependence. Note that different protocols can use the same cryptographic keys 
and still be strongly independent, and thus independent. 

Definition 25. Let n and Hi be two disjoint protocol sets. We say that n 
and Hi are strongly independent, denoted s-indep(n , III), if for any b G {0, 1}, 
any role specification (elist ■ send{m) • elist', type) in a protocol in IT;,, any role 
terms x, y, any role specifications (elist" ■ send(m!) ■ elist 1 " ', type') , (elist" ■ 
read(m!) • elist'", type') or (elist" ■ claim(r,c,m') • elist'" , type') in protocols of 
Hi-b, any map s on the set XV and any map s' on the set 1Z, 



Note that any map s on identifiers and s' on roles naturally induce maps on 
the set of role terms and we identify these maps with s and s'. Also note 
that since strong independence is a syntactical property, there is no need to 
consider trace restrictions. 

Theorem 26. If two protocol sets LTx and H 2 are strongly independent, then 
they are independent. 



Va G JV(IIi U n 2 ; x) Var, y, x', y' G RoleTerm : 




{ x } y C m { s(s'(x)) },(,'(„)) 2 m'. 
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Proof. Obvious from the fact that only nonce run terms are assigned to vari- 
ables and parameters. □ 



The notion of strongly independent protocols is obviously very strong, and 
there are many independent protocols that are not strongly independent. 
However, it is possible to verify strong independence by a simple syntactical 
check on the protocols. Obviously, strong independence may not be useful for 
analysing some existing protocols, but it does cover many deployed protocols 
(see Section 4). 

One way to achieve strong independence is to use separate key infrastructures 
for every protocol. Unfortunately, this is expensive and wasteful. A more prac- 
tical way to get strong independence is through protocol tags. Every protocol 
is given a unique tag which is embedded into every ciphertext the protocol 
makes. This trivially implies strong independence. 

Protocol tags may be a desirable approach for protocol design, since they 
typically require no extra bandwidth, and only modest extra computational 
effort. 

Modern signature schemes typically process the message to be signed with 
a hash function, create a signature tag, and attach the tag to the message. 
Adding a protocol tag of reasonable length (say 128 bits) to the message will 
usually result in a minor increase in the cost of computing the hash function. 
Since the signature is simply attached to the message, and both signer and 
verifier know the protocol tag, there is no need to actually transmit the proto- 
col tag. The signer can remove the tag from the message before transmitting, 
the verifier puts the tag back in before verifying. A signature made by one 
protocol will not pass the verification by a second protocol. 

Modern encryption schemes typically allow for part of the message to be left 
unencrypted but authenticated. Again, if we include the protocol tag in the 
unencrypted part, the encrypter can remove the tag before transmission and 
the decrypter can insert the tag prior to decryption. Typically, a protocol tag of 
reasonable length will result in a minor increase in the cost of authentication. 

As for hash-like function evaluations, most cryptographically interesting func- 
tions either allow the protocol tag to be inserted into the function evaluation, 
or allow cryptographic separation by choosing distinct parameters. The com- 
putational cost of most such measures are expected to be modest. 

To summarize, protocol tags typically have no bandwidth cost and modest 
computational cost. This suggests that protocol tagging is a viable and sensible 
strategy for protocol design. 
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3.2 Multi-protocol environments 



Once we have independence, we are ready to prove that any protocol remains 
correct in the presence of independent protocols. The general idea for proving 
all of the results in this section is to define maps between trace sets, and then 
argue that the predicate derived from a claim statement remains unchanged 
under this map. 

The next theorem says that if one protocol set keeps something secret, it will 
keep it secret even in the presence of a second, but independent, protocol set. 

Theorem 27. Let ITi and Il 2 be two independent protocol sets. Let t be the 
label of some secret claim event in U±. Then 



Proof. Let S be the set of nonce run terms in a originating in runs of roles 
from protocols in Il 2 . Let s : S — > XT be an injection such that no term in 
the image of s appears in a. We can extend s to the set of nonce run terms 
by letting s be the identity where it is not already defined. This map can then 
be extended naturally to a renaming map on the set of run terms. 

We construct a new trace a' from a by removing any events belonging to 
runs of roles from protocols in II2, and replacing any other event (inst, ev) by 
(s o inst, ev). (Since s renames only nonce run terms, the composition s o inst 
may affect only the a function of inst.) Note that by independence, if any 
nonce run term originates in a run of a role of a protocol in n 2 , the only way a 
run of a role of a protocol in II 1 will read that nonce run term is if the adversary 
also knows that nonce run term. From the semantics, we have that a nonce 
of II2 can only occur in a run of a role of TIi as a subterm of an instantiated 
variable. Therefore, if we replace the nonce run term by an attacker-generated 
nonce run term (such that the type constraints on the containing variable are 
met), the trace will still be valid even after the n 2 -events are removed. This 
means that a' G JV(IIi). 

There is always a canonical choice of injection s (given the well-ordering on 
the nonce run terms induced by the natural numbers) , and this gives us a map 



Note that r = s o 7r ni . 

Now consider a run term t claimed secret in a. In a', the corresponding run 
term is s(t), and we know that this is secret. We first determine why s(t) is 
secret, and we may as well assume that s(t) is a non-tuple run term. If s(t) 



sat(IIi,^) =>• sat(IIi LiU 2 ,£). 
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has the form f(u) for some function / and run term u, then t is secret by 
assumption. If s(t) is a nonce run term, we know that first of all s(t) must 
originate in a run of a role of a protocol in III. Second, every time it appears in 
a sent run term, it must be inside an encryption term. By independence, no U 2 - 
run will decrypt that ciphertext. Therefore, t must be secret in a. Otherwise, 
t must have the form ■{] u |}„ for some run terms u and v. If s(u) is secret, 
we must show that u is secret. We consider u instead of t and return to the 
start of the argument. Otherwise, s(v) must be secret. By independence, it is 
sufficient to show that v is secret, so we consider v instead of t and return to 
the start of the argument. 

Since terms cannot be infinitely nested, this argument chain must eventually 
stop, and in the process prove that t is secret in a. This concludes the proof. 

□ 

If secrecy of some nonce is not important for satisfying some secrecy claim in 
some protocol set, then passing the nonce to an independent protocol set will 
not compromise the secrecy claim. The intuition is that the worst an indepen- 
dent protocol can do is to reveal the nonce to the intruder, and therefore we 
only need to analyse what happens in that case. 

Definition 28. Let P be a protocol establishing c. Then P{c*) is the protocol 

P(c*) — {r 1— > s • send(r,u r0tri (r),c) ■ end(r) \ P(r) = s- end(r)}, 

where r and r\ are two distinct roles of P and z/ ro ri (r) is r when r 7^ r , 
otherwise r\. 

We extend this notation to protocol sets in the obvious way, writing II (c*). 

Theorem 29. Let Hi(c*) and ^{adversary / d) be two independent protocol 
sets and let I be the label of some secret claim event in U±. Then 

sat(n 1 (c*),^) sat(IIi(c) LiU 2 {c/d),e). 

Proof. It is clear that JV(n 1 (c) U n 2 (c/<i)) embeds naturally in JV(n 1 (c*) U 
U 2 (adversary / d)) . Furthermore, under this embedding the intruder knowledge 
is strictly increased. By Theorem 27, the secrecy claim holds in the latter trace 
set. It must therefore also hold in the former trace set and the theorem is 
proven. □ 

If secrecy of some nonce may be important for some secrecy claim, then passing 
the nonce to an independent protocol set that preserves the secrecy of its input 
will not compromise the secrecy claim. (Note that the secrecy claims in the 
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second protocol must be positioned at the start of the role. Otherwise, the 
protocol would be allowed to compromise the secrecy of the input as long as 
none of its roles reaches its secrecy claim.) 

Theorem 30. Let IIi(c) and U 2 (c/d) be two protocol sets, let C II i be 
a set of protocols establishing c and U 2 C II2 be a set of protocols with d 
as a parameter. Let t G IIi U II2 be the label of some secret claim event. If 
111 and n 2 are independent under the trace restrictions Xio(-] n' 1; IT 2 , c, d) and 
Xsecret(-]^2,d), then 

sat(IIi,{4} U {£}) Asat(n 2 (secret/rf),{<} U {£}) sat(IIi(c) U U 2 (c/d), £). 

Here we assume that {£i\ are the labels of claim events {claim^ri, secret, c)} 
in every role of every protocol in IIi that establishes c and the {£[} are labels 
of claim events {claim ^{r^, secret, d)} in every role of every protocol in Ii 2 
that has d as a parameter. The event claim e.{j\-, secret, d) is assumed to occur 
before any send or read event in the role specification. 

Proof. Let a G JV(II 1 (c) U U 2 (c/d)) be a trace. Let I be the set of indexes 
such that a, = (insti, create{r)) for some role r of a protocol Q in Ii 2 that 
takes c as input for the parameter d. For each i, define the set 

Ai = {j e I \ instj(d) = insti(d)}. 

Let ridi be such that a min A t = {{ridi, ■,•),■). Note that for any i E I, the 
nonce run term d%ridi never appears in a. Let S = {instiid) \ % e /} and 
S' = {d^ridi \ i e I}, and let s be the substitution that maps insti(d) to 
d%ridi for all i in I. 

We construct a new trace a' from a by replacing any event {inst, ev) that 
belongs to Ii 2 by the event (s o inst, ev). 

We claim that a' G Tr (IIi U U 2 (secret / d)) , and we get a map 

t : TV(IIi(c) U U 2 (c/d)) -> Tr^ U U 2 (secret/d)), (2) 

along with a natural bijection 

6 : M a -> M a '. 

We will prove the claim and construct the map 6 by induction. The theorem 
will then follow from a simple observation. 

Suppose a' Q ■ ■ •a^_ 1 is a valid trace. The subterm relation □ defines a partial 
ordering on Mj* and M"' . Let Uj and [/' be the minimal elements of these 
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sets, together with the terms that cannot be inferred from smaller terms: 

Uj = {xeMf\t □-minimal} U {fl t y eMJ\t£ Mf V t' g" Mf}, 
\J>. = {xe Mf I t □-minimal} U {$t y G Mf \ t Mf V t' & Mf}. 

Note that M" = Uj and Mf = C/j. Also note that any encryption term in Uj 
and Uj must originate from some send event. 

Define the sets 

Vj = {te Uj \3t' G S :t' C *} and Vj = {t G U- \ 3t' G S U s(S) : t' C t}- 

Let Vj 5 i and Vj j2 be the subsets of Vj of elements originating in LTi and il 2 , 
respectively. Let 

Vj A = {te U'j \3t' G S :t' Qt} 
Vj >2 = {te Uj | 3*' G s(S) :t'Qt} 

Let Wj = Uj \ Vj and W\ = U'j \ Vj. 

We can now prove the claim and construct the map 9 by induction on j. The 
induction hypothesis is that a' - • • is a valid trace and the following two 
properties hold for the structure of the intruder knowledge: 

(1) s n Vj = and (s u s(S)) n 17 = 0. 

(2) There exists a bijection 9 : Uj U'j such that restricted to Wj U Vj t \ is 
the identity map, and 9 restricted to Vj )2 corresponds to the map induced 
by the substitution s. 

Note that the bijection 9 extends to a bijection 9 : M" — > M?'. 

The induction basis is trivially satisfied for the empty trace and easy to verify 
for ckq. 

The trace restriction on d is satisfied by design, so if (X,- is a create event, 
«q • • • CKj- is a valid trace. Also, the same substitution is applied to all events in 
a run, so if ccj is a send, claim or end event, a' • • • a'j is a valid trace, because 
the instantiations will be consistent with the run (basically the instantiation 
of the last event). 

Next, we consider a read event ccj = (inst, read^m)), a'j = (inst', read^m)). 
We must prove that inst'(m) G Mf. We know that inst(m) G M". If 
inst(m) G Wj we are done, and a' • • ■ a'j is a valid trace. 

By independence we know that Vj t i H Vj i2 = 0. Again by independence, if 
£ G LTb, then any run term in Vj that is a subterm of inst(m) is also in Vj^, and 
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we get that inst(m) is in the closure of V jtb \JWj. Note that V-^UW- = V jt iUWj 
and VjpUWj = s(V ja UWj). If £ G I^ we have that inst'(m) = inst{m) G M"'. 
If £ G n 2 we must have that inst'(m) = s(inst(m)) G M? . Therefore, under 
the induction hypothesis, a' - • • a'j is a valid trace. 

We finish the inductive step by showing that (1) and (2) are also satisfied 
after the jth event. We need only consider the event otj = (inst, sende(m)), 
a'j = (inst 1 ', send e(m)). The only interesting inference rule is ({] t t') =>■ t, 
and we will show that the structure is unchanged by decryptions, up to some 
trivial rewriting. 

For any set of run terms T, let rcl(T) be the smallest set of run terms con- 
taining T that is closed under tuple creation and dissolution, encryption with 
known keys and removing signatures. This is the restricted closure, closure 
without decryptions. Note that M" = rcl(Uj). 

Under the induction hypothesis for U and U' , if we augment U by decrypting 
a run term {] t } t /, where t' G rcl(U), then we can augment U' by decrypting 
the run term 9({t$ t >), since 6 (if) G rcl(U'). If 9(t) = t, then clearly we 
augment U and U' in the same way. Likewise, if 6(t) ^ t, then 9(t) and t 
are equal up to substitution by s, and U and U' are augmented in the same 
way, up to substitution. This means that S C\U = 0, because we know that 
(S U s(S)) fl U' — 0. The maps can therefore be extended, and (1) and (2) 
still hold true after augmentation. Finally, if some of the elements in U are 
no longer minimal and are not encryptions that should be preserved, then the 
corresponding elements in U' will no longer be minimal, nor be encryptions 
that should be preserved. The other direction also holds. Therefore, we can 
discard all superfluous elements. 

The list Uj + i can be reached from Uj by adding the run terms obtained from 
the send event to the list, then performing a finite sequence of decryption 
operations, then possibly discarding some elements from the list. The above 
argument shows that the same operations (up to substitution) will turn C/j 
into Uj +1 in such a way that (1) and (2) still hold for Uj+i and U' j+1 . This 
completes the inductive step. 

To complete the proof of the theorem, we first observe that for any secrecy 
claim event aj = (inst, claimg(-, -,m)) there is a',- = (inst', claim^-, -,m)) and 
note that sat(IIi U U 2 (secret/d), i) is true by Theorem 27, thus inst'(m) G" 
M a . Next, if inst(m) G M a , then 9 (inst (m)) would be defined and equal to 
inst'(m), contradicting inst'(m) G" M a . We conclude that inst(m) G" M a and 
the secrecy claim holds. □ 

The following theorem states that protocol-centric claims remain valid if we 
execute a protocol in the context of another protocol that is independent of 
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the first. 



Theorem 31. Let IT and IT 2 be two independent protocol sets, and let £ be 
the label of some claim event in U±. If the security property associated with £ 
is protocol- centric, then 

sat(IIi,^) =>- sat(IIi un 2 ,l). 

Proof. Since IT and II 2 are independent, we can use the trace map r from 
(1) on page 25. Let P be the protocol where the claim event with label £ 
appears. By construction of the r map, we have s(np(a)) = -np{r(a)), for 
some substitution s. Since the claim is protocol-centric, we are done. □ 

When one protocol establishes session for some nonce run term, and a second 
protocol expects a session key as input, we can use the nonce run term from 
the first protocol as input to the second, without compromising any protocol- 
centric security properties. 

Note that in the following two results, we restrict to exactly one protocol 
creating output and one protocol taking input. This is for simplicity, and can 
easily be solved using protocol tags to create many distinct variants of a single 
protocol. 

Theorem 32. Let IT andU.2 be two protocol sets, such that P e II i is the only 
protocol establishing c and Q e II2 is the only protocol taking c as input for d. 
Let £ be the label of a protocol- centric claim event in IT or II 2 . //IT and n 2 are 
independent under the trace restrictions Xio\{-', P,Q,c,d) and Xsecret(-',Q,d), 
then 

sat(IIi, {£i} U {£}) A sat(n 2 (session/d), {Q U {£}) =>- sat(IIi(c) U U 2 (c\/d),£), 

where {£i} are labels of claim events {claim^ri, session, c)} in every role of 
P, and {£[} are labels of claim events {claim i'.{r\, secret, d)} in every role Q, 
occurring before any send or read event in the role specification. 

Proof. Let £ be in a protocol R. First, we note that the map r : JV(IIi(c) U 
IT 2 (c!/<i)) — > Tr (III U U2(secret/d)) from (2) on page 27 exists, since the 
session claims imply corresponding secret claims. Since for some substitution 
s, s(ii R (a)) = 7r^(r(a)), we only need to show that the session trace restriction 
is satisfied for the input to Q, and the result will follow from Theorem 31. 
Because of the data- agree claims, we have a full session for P, and by the 
session-unique claims, this session is unique. Thus for any end event for any 
role r of P, there are no other end events for that role with the same value 
for c. Hence, the session trace restriction is satisfied. □ 
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Finally, we combine the previous theorems into a statement about preservation 
of session secrecy. 

Corollary 33. Let 111 and H 2 be two protocol sets, such that P G IIi is the 
only protocol establishing c and Q G n 2 is the only protocol taking c as input 
ford. Let £ be the label of a (weak) session claim in Hi oriT 2 . IfH\ andU 2 are 
independent under the trace restrictions Xw\{'] P, Q, c ? d) and Xsecret('',Q,d), 
then 

sat(IIi, {£i} U {£}) A sat(U 2 (session/d), {Q U {£}) =>• sat(IIi(c) U U 2 (c\/d),£), 

where {£i} are labels of claim events {claim^ri, session, c)} in every role of 
P, and {£[} are labels of claim events {claim ^ij-^, secret, d)} in every role Q, 
occurring before any send or read event in the role specification. 

Proof. First we apply Theorem 27 and Theorem 31 to establish sat(n 1 U 
H 2 {session/d), {£i} U {£[}) (separately establishing the three parts of the ses- 
sion claims: secret, session- unique and data-agree). The results follows by fur- 
ther applications of Theorem 30 and Theorem 32. □ 



3. 3 Composition 



In this section we study sequential composition and show how certain secu- 
rity properties of a composed protocol follow from security properties of the 
subprotocols analyzed in a multi-protocol setting. 

As discussed in Section 1, sequential composition (without passing informa- 
tion) of two protocols does not in general preserve synchronisation. The prob- 
lem is that if there is no mechanism to bind the two subprotocols to each 
other in the composed protocol, different runs can be interleaved with each 
other, breaking synchronisation. Therefore, there must be a mechanism that 
connects the two subprotocols. We achieve this by letting the first subprotocol 
pass information to the next subprotocol. (A slightly more general definition 
of chaining composition allowing more than one parameter appears in PCL.) 

Definition 34. Let rs\ = (elisti ■ end(r), type^ and rs 2 = ( create (r)- 
elist2,type 2 ) G RoleSpec. The sequential composition of role specifications rs\ 
and rs 2 is the role specification rs\ • rs 2 = (elisti ■ elist 2 , type) where 



type(x) = < 



type^x) if type^x) is defined; 

type 2 (x) if type^x) is undefined and type 2 [x) is defined; 
undefined otherwise. 
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Definition 35. Let P and Q be two protocols such that dom(P) = dom(Q), 
1T>(P) r\1T>{Q) = 0. If P establishes c, and d is a parameter in all roles of Q, 
the chaining composition P ■ Q of P and Q is defined as: 



where Q(r)[c/d] denotes replacing d by c in the role specification Q(r). 

Note that every event is relabeled after this composition, but there is a nat- 
ural correspondence between the labels of P and Q, and the labels of P ■ Q 
(excluding the end event of P and create event of Q). 

The formal model described in Section 2 allows us to define explicitly the 
concept of passing information from one protocol to another. This exactly 
coincides with the idea of input and output, modeled using parameters. How- 
ever, simply passing information does not suffice to preserve synchronization. 
Intuitively, if agents of the first subprotocol do not all share the value to be 
passed on to the next subprotocol, a mismatch between different runs of the 
agents may occur and synchronization may be broken. Likewise, the next sub- 
protocol must ensure that all agents got passed the same value. In order to 
ensure this, we use data agreement for the value passed between subprotocols. 

Theorem 36. Let P, Q be protocols such that P establishes c, d is a parameter 
in all roles of Q and P ■ Q is defined. Let II be a set of protocols, P,Q ^ 
LT. Let be a set of labels for one injective synchronization claim event 
and one data agreement claim event with argument c in every role of P , the 
synchronization claim events appearing after all read and send events in the 
role. Let £ and £' be the labels of a data agreement claim event with d as 
argument and an (injective) synchronization claim event, respectively, in some 
role Q such that the claim event labelled £ causally precedes the one labelled 
£'. Let £" be the label of a corresponding injective synchronization claim event 
inP-Q. Then 



Proof. LetaE Tr({P-Q}UlVj. We map a to a trace a' E Tr({P(c),Q(c\/d)}U 
IT) as follows: Without loss of generality we can assume that the set Runid of 
run identifiers is a subset of non-negative integers. Let the highest occurring 
run identifier in a be rids, and suppose we have a run with run identifier rid 
of a role r of P ■ Q with events a ix , a i2 , . . . , a ik . If there is no event in the run 
corresponding to an event of the protocol Q, we relabel all of the events to be 
events of P. Otherwise, let ii be the first event in the run corresponding to an 
event of Q. 

(1) We relabel a^, . . . , cti ! _ 1 to be events of P, and a^, . . . , cti k to be events 




sat({P(c), Q(c\/d)} U II, {£i} U {£, £'}) =>■ sat({P • Q} U IT, £"). 



of Q. 
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(2) We change the a-parts of the instantiations of a^, . . . , ai k so that they 
are only defined at identifiers of Q. 

(3) We change the run identifier of a it , ... , a ik to rid + rids + 1. 

(4) We apply to every other event in the trace the substitution {x%rid \— > 
x%rid + rids + 1 | £ G XV{Q) A type(x) = const}, where Q(r) = 
(elist, type). 

(5) We insert a end for P(r) and a create event Q(r) with the proper value 
for the parameter d just before a it in the trace. 

When this operation is performed for every run of a role of P • Q, we get a 
trace a' G Tr({P(c), Q(c\/d)} U II), and this gives us a map 

r : Tr{{P ■ Q} U II) -> Tr({P(c), Q(c!/d» U n). (3) 

Now consider a run of role r with run identifier rirf r where the claim event 
with label I" occurs. First, we note that because of injective synchronization 
for P, we have a unique cast cast for P in a'. This translates into a potential 
cast cast' for Q in a' given by cast'{r') = cast(r) + rids + 1, as well as a cast 
for P ■ Q in a. By data agreement for c in P, we know that every run in the 
cast agree on the value of c. Since P does not take any input, the value of 
c must originate with one of the roles, hence it must also be unique among 
all the runs of P. Further, by data agreement on d in Q, we know that cast' 
really is a cast for Q in a', it is unique, that every member of the cast agrees 
on the value of d, and that this value is the same as the value of c. 

Now we verify the i-synch claim with label £" for rid r in a with the unique cast 
cast. Consider a role r' and a label £ x such that £ x G P-Q(r) and £ x G P-Q(r'). 
We must show that there are two events with this label in a, belonging to the 
cast, and sending and reading the same message. Because of synchronization in 
a', we find matching events belonging to the cast for the corresponding labels 
in a'. Note that since the map r only changes instantiations by applying a 
substitution, if the content of the messages is the same in a', the same must 
hold in a. We conclude that the injective synchronization claim with label £" 
is satisfied in a. □ 

The following theorem states the conditions under which secrecy is preserved 
in a sequential protocol composition. 

Theorem 37. Let P , Q be protocols such that P establishes c, d is a parameter 
in all roles of Q and P -Q is defined. Let U be a set of protocols, P,Q G^ II. Let 
£ be the label of a secret claim event in P or Q, and let £' be the corresponding 
label in P • Q. Then 

sat({P(c), Q(c\/d}} UU,£)^ sat({P • Q} U II, £'). 
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Proof. We use the map r from (3). Note that instantiations are changed by at 
most a nonce run term renaming under this map, so the intruder's knowledge 
is also changed by at most a nonce run term renaming. The predicate derived 
from the secret claim does not change its value under nonce run term renaming, 
from which the result follows. □ 

The same conditions that preserve secrecy, also preserve session-unique and 
data- agree in a sequential protocol composition. 

Theorem 38. Let P , Q be protocols such that P establishes c, d is a parameter 
in all roles of Q and P • Q is defined. Let H be a set of protocols, P,Q ^ II. 
Let £ be the label of a session-unique or data-agree claim event in P or Q, 
and let £' be the corresponding label in P ■ Q. Then 

sat({P(c), Q(c\/d)} un,f)^ sat({P • Q} U n, £'). 

Proof. We use the map r from (3). By the construction of the map, if some 
value only appears in one claim event in r(a), it will only appear in one claim 
event in a as well. This proves the theorem for session-unique. 

As for data agreement, if events for some cast exist in r(a) with the correct 
value, they will also exist in a. This proves the theorem for data- agree. □ 

By definition of session and wsession, the preceding two theorems give condi- 
tions under which these two properties are preserved. This is expressed in the 
following 

Corollary 39. Let P , Q be protocols such that P establishes c, d is a parame- 
ter in all roles of Q and P -Q is defined. Let IT be a set of protocols, P,Q ^U. 
Let £ be the label of a (weak) session claim event in P or Q, and let £' be the 
corresponding label in P ■ Q. Then 

sat({P(c), Q(c\/d)} un,^ sat({P • Q} U II, £'). 

Proof. We use Theorem 37 and Theorem 38 to establish that the requisite 
secret, session-unique and data- agree claims hold, and the result follows. □ 



4 Mobile WiMAX 

In this section we apply our framework to a handful of protocols from the 
security sublayer of the IEEE 802.16-2005 amendment [28] of the IEEE 802.16- 
2004 standard [27], commonly and in the following referred to as (mobile) 
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WiMAX. The aim is not a complete verification of WiMAX as this would 
constitute a research topic of its own. Instead, we use WiMAX to illustrate 
our framework on a real- world protocol suite and as a measure for our progress 
towards the goal of a comprehensive theory of protocol verification. We stress 
that even in the limited setting we consider, our methods are strong enough 
to draw useful conclusions about protocol design and security flaws. 



4-1 Introduction 

The IEEE 802.16-2004 standard specifies the air interface of fixed broadband 
wireless access systems supporting multimedia services in local and metropoli- 
tan area networks. The 802.16-2005 amendment addresses mobility of sub- 
scriber stations and features new security protocols. 

A brief overview of the communication between a mobile station and base sta- 
tion follows. The communication starts at the mobile station's network entry 
with the Ranging protocol. Its purpose is to set up physical communication 
parameters and assign a basic connection identifier to the requesting mobile 
station. This protocol is periodically executed later to re-communicate the 
physical communication parameters. Next, a Registration protocol is carried 
out in order to allow the mobile station into the network. During this proto- 
col, the base station and mobile station's security capabilities are negotiated. 
The base station and mobile station can agree on unilateral or mutual au- 
thentication, or no authentication at all, and on a variety of key management 
protocols. The key management protocols are periodically repeated to update 
the traffic encryption keys. The entire authentication chain is repeated on a 
less frequent basis. Once the traffic encryption keys are established, user data 
protocols start. To avoid service interruptions, traffic encryption keys have 
overlapping lifetimes. 

The authentication and key management protocols are specified in the security 
sublayer of WiMAX. The security sublayer is meant to provide subscribers 
with privacy and authentication and operators with strong protection from 
theft of service [28, Chapter 7]. It employs an authenticated client /server key 
management protocol in which the base station controls distribution of keying 
material to the mobile station. 

The security sublayer consists of two component protocols, an encapsulation 
protocol for securing packet data across the network and a key management 
protocol providing the secure distribution of keying data from the base sta- 
tion to the mobile station. In the following sections we will focus on the key 
management protocol. Through this key management protocol, the base sta- 
tion and mobile station are to synchronize keying data and the base station 
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is meant to use the protocol to enforce conditional access to network services. 

The overall security goals mentioned in the specification are "no theft of ser- 
vice" for the operator of the base station and "confidentiality" for the user of 
the mobile station. Confidentiality in WiMAX is defined to be "privacy" and 
"authenticity" [28, Chapter 7, footnote 6]. The specification gives vague ideas 
for the security properties that the subprotocols have, by calling them for in- 
stance authentication protocols or key update protocols. But for a thorough 
security analysis, precise security claims need to be made for each subprotocol 
and the relation between the security properties achieved by the subprotocols 
and the overall security goals needs to be understood. We are addressing these 
issues in the following section. 



4-2 Key management in the Security Sublayer 

The privacy key management (PKM) component of the security sublayer con- 
sists of authentication and key establishment protocols. Depending on the 
negotiated security capabilities, the IEEE-802. 16-2004 PKM protocols or the 
new PKM version 2 protocols will be executed. In the following security anal- 
ysis, we consider the sequence of the three PKM version 2 protocols PKMv2 
RSA, PKMv2 SA-TEK, and PKMv2 Key. PKMv2 RSA authenticates the base 
station (bs) and mobile station (ms) and establishes a shared secret which is 
used by PKMv2 SA-TEK and PKMv2 Key to secure the exchange of traffic 
encryption keys (TEKs). WiMAX does not explicitly state what the security 
claims of these three protocols are. As indicated in the Introduction, it is 
stated that the sequential composition of the three protocols achieves strong 
authentication and privacy for the mobile station, and strongly protects the 
base station from theft of service. Furthermore, it is implicitly stated that 
the established keys are shared secrets and PKMv2 RSA is called a mutual 
authentication protocol. 

We are making these properties more precise by imposing the following require- 
ments on the composition of the three protocols. In order to provide "strong 
protection against theft of service" [28, Chapter 7] for the base station, the 
client station has to be strongly authenticated at the end of the protocol com- 
position, i.e. the role of the base station has to satisfy the i-synch claim and 
all key material must be secret. Note that if the i-synch claim is true at the 
end of the protocol composition then we are guaranteed that every message 
read by bs up to that point has been sent by ms and exactly matches the 
message sent by ms. Thus no theft of service can have occurred up to that 
point. In order to provide privacy and authenticity for the subscriber station, 
we demand that the base station is strongly authenticated at the end of the 
protocol composition, and that all session keys and symmetric encryption keys 
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are secret and unique. 



We argue now that the following security properties for the three protocols and 
their sequential composition need to be fulfilled and prove in the next section 
that these properties indeed imply our set security goals. Since PKMv2 RSA 
needs to authenticate ms and bs and establish a shared secret which is to be 
used as a key later on, it has to satisfy i-synch for both roles and session for 
the shared secret. Since PKMv2 SA-TEK and PKMv2 Key need to establish 
further keys while keeping up the authentication property between ms and 
bs, they both need to satisfy synch for both roles, session for the shared 
secret, and at least wsession for the traffic encryption This implies 

in particular that the shared secret and traffic encryption keys have to be 
secret in all three protocols. We summarize these requirements in Table 2. It 
corresponds to the summary of verified security properties in Section 4.3.4. 



Protocol 


Security Properties 


PKMv2 RSA 
PKMv2 SA-TEK 
PKMv2 Key 


i-synch, session(pPAK) 

i-synch, session(pPAK), wsession(TEK) 

synch, session(pPAK) , wsession(TEK) 



Table 2 

Required security properties for the PKMv2 subprotocols in WiMAX. 

Before we start the description of the protocols, some technical remarks on 
our WiMAX model are in order. We will restrict ourselves to non-handover 
scenarios with unicast communication, leaving out multicast and broadcast 
communication, mesh communication, and group security. We further restrict 
ourselves to one Security Association as opposed to a list of several security 
associations offered by the base station. This is simply for convenience as 
it implies that there is only one pair of TEK keys instead of several pairs 
identified by SAID's and managed by parallel sessions of the PKMv2 Key 
protocol. 

In our model, we have simplified messages by omitting irrelevant terms and 
headers. In particular, the fact that all messages in WiMAX are formatted 
using a type/length/value (TLV) scheme, we show only implicitly by giving 
appropriate names to identifiers. Entries in a TLV list are called attributes. 
WiMAX specification states that both roles silently discard all messages that 
do not contain all required attributes and skip over unknown attributes. Note 
that the use of TLVs together with signatures and hashed message authenti- 
cation codes in WiMAX also implies that we may disregard type flaw attacks. 
Finally, we model hash functions as encryptions with a special public key, 
known by all parties, whose inverse key is not known by anyone. We thus 

4 Since wsession and data- agree imply session, the use of the TEKs in user data 
protocols by both roles will automatically imply the session claim at that point. 
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write H m fyh(sait) f° r the message m to which a message authentication code 
has been attached. Private key signatures will be indicated by -fl m ^ s k(ms) and 

4.2.1 PKMv2 RSA 

The PKMv2 RSA protocol (Figure 4) is the initial mutual authentication pro- 
tocol. It is repeated periodically to update the pPAK. Its purpose is to establish 
a shared secret pPAK (called pre-PAK in WiMAX) between ms and bs. The 
shared secret is used to derive the authentication key from which the keys for 
hashed message authentication codes and symmetric encryptions are derived. 

According to specification, the Request message consists of MS-Rnd, MS-Crt, 
SAID and a signature over a SHA-1 hash of these fields using ms's secret 
key, whose corresponding public key bs learns from MS-Crt. We model this 
by sending MS-Crt outside of -fl . . . §sk(ms)- The same applies to BS-Crt in the 
Reply and Reject messages. 

4.2.2 PKMv2 SA-TEK 

The PKMv2 SA-TEK protocol (Figure 5) is a three-way handshake protocol 
which follows the PKMv2 RSA protocol. Its purpose is to update the traffic 
encryption keys if they already exist. The protocol's messages are authen- 
ticated by hashing them with keys derived from pPAK established by the 
PKMv2 RSA protocol. Different keys are used for uplink and downlink traffic. 
The base station sends a challenge to the mobile station, which the mobile 
station repeats in its request for updated key material and thus proves live- 
ness and knowledge of the shared secret (by using the derived HMAC key) to 
the base station. The base station answers then with updated key material, 
repeating the mobile station's nonce. 

4.2.3 PKMv2 Key 

The PKMv2 Key protocol (Figure 6) allows the mobile station to obtain the 
most recent TEK key from the base station. 

4-3 Applying the Framework 

We begin by analyzing the three protocols described in the previous section in 
isolation and then we apply our theorems to their sequential composition. To 
facilitate later exposition, we will, during the course of the analysis, simplify 
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PKMv2-RSA 

MAN- Crt, MS- Crt, pk(ca) 



BS-Crt,pk(ca) 



ms 



Auth Info 



bs 



MAN- Crt 



MS-Rnd 



Request 



or 



Reply 



Reject 



Acknowledgment 



MS- Crt, jj MS-Rnd, SAID, MS- Crt l sk(ms) 



BS-Rnd, pPAK 



BS-Crt,{ MS-Rnd,BS-Rnd,S\ pPAK,ms^ vk{ms) ,B8-CH\ sk{bs) 



BS- Crt, jj MS-Rnd, BS-Rnd, BS- Crt $ sk(bs) 



| BS-Rnd } afe(r 



MAN- Crt 


manufacturer's certificate 


MS- Crt 


mobile station's certificate {| ms,pk(ms) ftsk(man) 


BS-Crt 


base station's certificate -fl bs,pk(bs) § s k(ca) 


SAID 


security association Id, equal to BCID 


MS-Rnd 


mobile station's nonce 


BS-Rnd 


base station's nonce 


pPAK 


preliminary primary authentication key, 

actually another nonce created by the base station 



Fig. 4. The PKMv2 RSA protocol. 



the protocols presented above. Since the aim of this work is not a careful and 
formal analysis of these short subprotocols, we will reason on an informal level 
for clarity, backed up by the automated verification tool Scyther. After that, 
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PKMv2 SA-TEK 
ARID, TEK , TEKi 



AKILf , TEK , TEKi 



ms 



Challenge 



bs 



jj BS-Rnd', AKItf h(HMAC-KD) 



BS-Rnd' 



MS-Rnd' 



Request 
Response 



| MS-Rnd!, BS-Rnd', ARID h(HMAC-KU) 



{ MS-Rnd' , BS-Rnd' ,AKID,i TEK' , TEK\ ^kekH(hmac-kd) 



PAR 


Primary authentication key derived from pPAR as fol- 
lows: 

PAR = keyedhash(pPAR, ms bs). 


AR 


Authentication key derived from PAR as follows: 
AR= keyedhash(PAR, ms bs PAR). 


RER 


key encryption key derived from AR as follows: 

HMAC-RU | HMAC-RD | RER 
keyedhash(AR, ms bs). 


HMAC-RD 


HMAC key derived from AR for authenticating down- 
link communication 


HMAC-RU 


HMAC key derived from AR for authenticating uplink 
communication 


MS-Rnd' 


mobile station's nonce 


BS-Rncf 


base station's nonce 


ARSN 


AR sequence number, essentially a 2 bit counter 


ARID 


AR Id: ARID = keyedhash(AR, ARSN | ms | bs) 


ARID 1 


AR Id of new AK if re-authenticating 



Fig. 5. The PKMv2 SA-TEK protocol, 
we will analyse the composition in detail. 
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PKMv2 Key 

TEK , TEKi TEK , TEK t 



ms 


6s 








n 




Request 


II n Vh(HMAC-KU) 




or J 

Reply 


{ 1 , T£i^ n ^ (FMj4 c-KD) 






Reject 















TEK 


Older traffic encryption key 


TEK X 


Newer traffic encryption key 


TEK , TEK-y 


Updated traffic encryption keys, replacing TEK , 
TEK\, respectiveljOD 


KEK 


Key Encryption Key (see above) 



Fig. 6. The PKMv2 Key protocol. 



4.3.1 Analysis of PKMv2 RSA 

We analyze the PKMv2 RSA protocol without the Auth Info message which 
according to specification is only being sent right after Ranging and never 
again. We first consider i-synch for ms and bs and then the session property 
for pPAK. 



4.3.1.1 i-synch. Since we have a choice in the third message between Reply 
and Reject, we will first analyze the branch with Reply, then the branch with 
Reject. 

Reply. Note that the structure of Request, Reply, Acknowledgment is similar 
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to the standard X.509 protocol, except for the last message where the iden- 
tity of bs is missing. As a consequence, it suffers from a man-in-the-middle 
attack causing bs to not synchronize. The intruder executes the man-in- 
the-middle attack by taking advantage of an ms trying to connect to the 
intruder and redirecting those messages to a bs. In [43] the authors describe 
a similar, but slightly more complicated attack, in which the intruder uses 
two runs of ms to impersonate ms to bs. Both attacks can be found using 
Scyther. 

The attacker can not, however, impersonate bs to ms, and the ms role in 
fact still synchronizes and the pPAK remains secret. It is also interesting 
to note that Request, Reply, Acknowledgment followed by PKMv2 SA-TEK 
has agreement (an authentication property slightly weaker than synchroni- 
sation, see [16]) for both ms and bs. However, we still consider the lack of 
frs's identity in Acknowledgment a design flaw, since it is supposed to be a 
"mutual authentication" protocol according to specification and hence, in 
its current form, breaks a modular design principle: small changes in other 
protocols (for instance PKMv2 SA-TEK) could break the security of the 
entire composition. 

For future reference, we write P to denote the protocol consisting of Re- 
quest, Reply, and Acknowledgment 1 where Acknowledgment 1 is the message 
{] BS-Rnd, bs ftsk(ms) from ms to bs. Furthermore, we will denote the pPAK 
in P simply by c. P has injective synchronization for both roles. 
Reject. As in the branch analyzed above, the structure Request, Reject, Ac- 
knowledgment resembles the X.509 standard. Here however, both Reject and 
Acknowledgment are missing the recipient's ID. Therefore neither bs nor ms 
synchronize (the weaker agreement notion is not satisfied either). A pPAK 
is not being sent, thus the secrecy claim is void. The fact that ms does not 
synchronize can be abused for a denial of service attack. 



We amend the flaws pointed out above by considering P instead of PKMv2- 
RSA. Note the absence of a Reject message from P. A Reject message sent 
from bs to ms terminates the protocol. In order for ms to communicate with bs 
it has to start over with the Ranging protocol. For this reason, we will simplify 
the analysis of the composition in Section 4.3.4, without affecting any of the 
security properties we are interested in, if we consider the protocol without the 
Reject message; instead of a send event corresponding to the Reject message, 
the run of the bs role ends. 



The specification of protocol P is given below. For brevity, we omit the typing 
of identifiers and use the shorthand for the message contents as displayed in 
Figure 4. The descriptive labels of the claim events are inserted for further 
reference. 
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P(ms) = createpi(ms) ■ send P2 (ms, bs, Request) ■ readp 3 (bs, ms, Reply)- 

send P4 (ms, bs, {] BS-Rnd, bs $ s k(ms)) • claim i . synch ^ P>ms )(ms, i-synch)- 

claim session (p !mSiC )(ms, session, c) ■ end P5 (ms) 
P(bs) = createp§(bs) ■ readp 2 (ms, bs, Request) ■ sendp 3 (bs, ms, Reply)- 

read P4 (ms, bs, { BS-Rnd, bs $ sk ( ms )) • claimi_ synch{Pjbs} (bs, i-synch)- 

claim session(p,bs,c)(bs, session, c) ■ end P7 (bs) 

In the remainder, we will use the abbreviation i-synch(P) to stand for the 
combination of i-synch(P, ms) and i-synch(P, bs). We will use similar abbre- 
viations for the other claims and protocols. 

Using Scyther, we prove synchronisation. Given the fact that P satisfies the 
loop-property from [16], we establish 

s&t{{P},{i-synch{P)}). 

4.3.1.2 session. We use Scyther to verify that pPAK is secret. The data- 
agree property is satisfied because of injective synchronization, and the fact 
that pPAK is part of a message causally preceding the synchronization claims. 
Finally, session-unique is also satisfied because of injective synchronization 
and the fact that pPAK is a constant in one of the roles appearing only in one 
send event, accompanied, within a signature, by the recipient's nonce. 

The established result is 

sat({P}, {session(P, c)}). 
4.3.2 Analysis of PKMv2 SA- TEK 

We call Q the protocol obtained from PKMv2 SA-TEK by introducing the 
parameter d, which will obtain its value from the constant c produced by 
protocol P. The parameter d will hold the shared secret established in P from 
which the HMAC and KEK keys are derived. Furthermore, the collection of 
TEK keys will be denoted by e in Q. Thus, Q is up to renaming of constants 
equivalent to PKMv2 SA-TEK. 

We insert session claim events for d, weak session claim events for e, and 
injective synchronization at the end of both roles, with labels session(Q, ms, d), 
session{Q , bs, d) , wsession(Q,ms,e), wsession(Q,bs,e), i-synch{Q,ms), and 
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i-synch(Q, bs). This yields the following description of protocol Q (assuming 
hi, h2, and h3 are distinct hash functions). 



Q(ms) = createQi(ms) ■ readQ2(bs, ms, -fl BS-Rnd , AKID 1 ^hi(d))- 
send Q3 (ms, bs, {] MS-Rnd 1 ', BS-Rnd, AKID§ h2 (d))- 
read QA (bs, ms, { MS-Rnd, BS-Rnd, AKID, { e § h3{d) } h i{d))' 
claim i- S ynch(Q,ms)(ms, i-synch) ■ claim session{Q ^ ms4) (ms, session, d)- 
claim wseS sion(Q,ms,e)(ms, wsession,e) ■ end Q5 (ms) 

Q(bs) = createQQ(bs) ■ sendQ2(bs, ms, {| BS-Rnd, AKIL/ §hi(d))- 
read Q3 (ms, bs, { MS-Rnd, BS-Rnd, AKID } h 2(d))- 
send Qi (bs, ms, {] MS-Rnd, BS-Rnd, AKID, -fl e 1^ $ h i(d))- 
claimi_ synch (Q^ s) (bs, i-synch) ■ claim session ( QMyd )(bs, session, d)- 
claim wseS sion(Q,bs,e)(bs, wsession,e) ■ end Q7 (bs) 

Again, we verify injective synchronization and secrecy for d and e using Scyther. 
Note that the verification has to be done for the trace restriction Q {session /d). 
Session trace restrictions can be simulated in Scyther using technical tricks, 
but are expected to be supported natively in the future. 

The session-unique property follows from arguments analogous to the ones 
shown for c in P and the session trace restriction for both d and e. Data 
agreement for d follows from injective synchronization and the appearance of 
d in a message causally preceding the i-synch claim for both roles. For e we 
do not get data agreement for the bs role, since e is sent in the last message 
for which bs has no guarantee that ms received it. 

We have shown 

sat({<3 {session/ d)} , {session(Q, d), wsession(Q, e), i-synch{Q)}) 
4.3.3 Analysis of PKMv2 Key 

Similarly to the previous two protocols, we will let R denote the protocol 
obtained from PKMv2 Key by denoting the EM AC keys by d, the old TEK 
keys by e and the new TEK keys by e'. We let R only consist of the Request and 
Reply messages, since the alternative has exactly the same security properties. 

We have i-synch for the ms role, shown by applying Scyther and using the 
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loop property, but only synch for bs. 



The session property for d and wsession property for e' can be shown in 
exactly the same manner as for the Q protocol. 



R(ms) = create Ri(ms) ■ send R2 (ms, bs, -fl n $h2(d)) • 
read m (bs, ms, ^e' $ h3 (d),n hi(d))- 

clainii_ synch ( Ryms) (ms, i-synch) ■ claim seS sion(R,ms,d)(rns, session, d)- 
claim wseS sion(R,ms,e')(rns, wsession, e') ■ end R5 (ms) 
R(bs) = create m(bs) ■ read R2 {ms, bs, {] n }h2(d))- 
send m (bs, ms, ^ e' } w(d ), n }hi(d))- 

claim sy nch(R,bs)(bs, synch) ■ claim session ( RMd) (bs, session, d)- 
claim wsession ( RMe >)(bs, wsession, e') ■ end R7 (bs) 

Abbreviating the claim labels, we obtain 

s&t({R{session/ d)} , {i-synch(R, ms), synch(R, bs), 

session(R, d), wsession(R, e')}). 

4-3.4 The composition 

In the preceding three subsections we have established that 

sat({P}, {i-synch(P), session(P, c)}) (4) 
sat({Q {session/ d)} , {session(Q, d), wsession{Q, e), i-synch(Q)}) (5) 
sat( {Risession I d)}, {i-synch(R, ms), synchiR, bs), 

j (i j 

session(R,d),wsession(R,e')}) 

The methodology for the verification of these facts is standard. In what fol- 
lows, we apply the collection of theorems in our framework to show how the 
established properties imply correctness of the composed protocol P ■ Q ■ R. 

Note that P, Q, and R are mutually strongly independent since the messages, 
as stated in Section 4.2, are TLV encoded, the signatures or hashed mes- 
sage authentication codes are made over the entire message, and the message 
structures are different in the three protocols. More precisely, protocol P is 
independent from Q and R because all messages in P are signed by private 
keys and hence the signatures will not be accepted by either role in protocols 
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Q and R, their messages being authenticated using the shared secret keys. 
Protocols Q and R are strongly independent, since they don't have a message 
in common in which all required attributes are identical. 

Using strong independence, we can now deduce that P followed by Q satisfies 
injective synchronization, session, and weak session as follows. 

By Theorem 32 and equations (4) and (5), we can preserve the i-synch prop- 
erty for P, Q. By Corollary 33, c and d keep the session property, and e the 
w session property. 

Therefore, we obtain 

sat({P(c), Q{c/d)}, {i- synch (P), i-synch(Q), 

session(P, c), session{Q, d), wsession(Q, e)}), 

and using Theorems 36 (to obtain i-synch), and Corollary 39 (wsession and 
session) we get 

sat({P • Q}, {i-synch(PQ), session(PQ, c), wsession(PQ, e)}). (7) 

Here we assume that in the composed protocol P • Q roles bs and ms are 
extended with appropriate claim events. We use the three labels i-synch(PQ), 
session(PQ,c), and wsession(PQ,e) to refer to these claims. 

Next, by Theorem 32 we establish from (6) and (7) injective synchronization 
for both roles and by Corollary 33 session for c and wsession for e: 

sat({P • Q(c), R(c/d)}, {i-synch{PQ), 

session(PQ, c), wsession(PQ, e), 
i-synch(R, ms), synch(R, bs), 
session(R, d), wsession(R, e')}) 

Using Theorem 36 and Corollary 39 one more time, we can show that the entire 
composition satisfies injective synchronization and (weak) session secrecy for 
the shared secret c and the traffic encryption key e: 

sat(P • Q ■ R, {i-synch(PQR), session(PQR, c), 

wsession(PQR, e), wsession(PQR, e')}) 

These are exactly the overall security properties we have formulated in Sec- 
tion 4.2. As we have shown in that section, these security properties are a 
precise interpretation of the security goals stated in the WiMAX specifica- 
tion. 
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4-4 WiMAX: Conclusion and related work 



We have verified that the sequential composition of the key management pro- 
tocols PKMv2 RSA, PKMv2 SA-TEK, and PKMv2 Key satisfies strong au- 
thentication and session secrecy for keys derived from the shared secret and for 
traffic encryption keys. However, in order to achieve this verification, we had 
to first formulate precise security properties for the subprotocols and their 
composition, based on our interpretation of the rather vague security goals 
specified in WiMAX. 

While we have shown that our strong authentication property i- synch holds 
for the protocol composition as stated, it has to be noted that a composition 
consisting of repeated iterations of the PKMv2 Key protocol would fail to 
satisfy this property, due to replay attacks. In practice, such attacks would 
only be a nuisance, not a security threat, since secret would still hold true for 
all keys, and such an active intruder would not be able to learn anything more 
than a passive, listening, one. Thus, in future work, the WiMAX protocols 
will be analyzed with an appropriately weakened notion of authentication. 

Although several studies on WiMAX security have appeared, none of these 
offer a precise and compositional verification of the WiMAX key management 
protocols. Closest to our work is a preliminary study in [31], which sketches 
the steps towards a compositional verification. An analysis of some protocols 
from the 2001 version of the WiMAX standard is conducted in [29]. Their main 
observation is that the old protocols achieve unilateral authentication, while 
mutual authentication of bs and ms is required. The proposed fixes clearly 
found their way into the current standard. However, the protocols are studied 
in isolation and the authors did not apply formal reasoning to prove the fixed 
protocols correct. Xu et al. [43,44] analyzed several isolated protocols from the 
current WiMAX standard. Through informal reasoning, they discovered the 
attack mentioned in Section 4.3.1 and proposed a fix. The modified protocol 
is proved correct by using the BAN-logic [9] , which is known to be incomplete 
with respect to insider attacks. Finally, we mention an analysis of the cur- 
rent WiMAX standard using the TLA+ logic in [44]. The authors study the 
composition of the three mentioned key management protocols as one single 
protocol. Exploiting symmetry reduction techniques, they manage to apply 
the TLC model checker to verify the composed protocol. However, their focus 
is not on the key management properties that we investigate (such as authen- 
tication and secrecy), but on detecting a class of denial-of-service attacks. In 
order to validate liveness, they focus on the state machines underlying the 
protocols. 
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5 Related Work 



In this section we address work related to the composition of security protocols. 
We discuss strand spaces, as well as the more recent Protocol Composition 
Logic, in some detail below. Afterwards we address related theoretical results, 
and discuss some attempts at the verification of composed protocols. 



5.1 Strand Spaces 

Within a modified version of the Strand Spaces framework [41], called the 
Mixed Strand Spaces model [42], some results about compositionality have 
been proven. In [23], a disjoint encryption theorem is proven. This theorem 
states that if two protocols have sufficiently different encrypted messages (at 
the trace/run level), composing them in parallel will not introduce new at- 
tacks. In terms of methodology, this work is closely related to ours: given any 
two correct protocols, what abstract properties should they satisfy, in order 
to ensure that their composition is correct? 

The main differences between their approach and ours, are that (1) they only 
consider parallel composition, and (2) verification of the disjoint encryption 
property has to be done at the level of traces. With respect to the first item, 
we note that the approach does not allow for the decomposition of large se- 
quential protocols into smaller ones, as can be done with the chaining theo- 
rems presented here. Similarly, there are no concepts such as session-secrecy. 
Consequently, the disjoint encryption approach cannot be used for the compo- 
sitional verification of strongly dependent subprotocols such as those present 
in WiMAX, for instance. 

The second item represents a more significant drawback of the approach. The 
verification of disjoint encryption has to be performed at the trace level of the 
composed protocols. For some protocols, this can be easily, but nevertheless 
manually, deduced from the protocol specification, but in many other cases 
(e.g. where session keys are used in protocols) the only way to verify that the 
disjoint encryption property holds is by inspecting the traces of the composed 
protocol. Therefore, in such cases there is no expected improvement on the 
more traditional approach of, for example, model checking all traces of the 
composed protocol. 

As a more subtle drawback, the proof given for the disjoint encryption theorem 
assumes that the security properties do not include ordering constraints. Thus, 
it is not immediately possible to apply the theorem for the verification of strong 
authentication properties, such as e.g. the synchronization property. 
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One advantage of the approach is that their results also hold for protocols 
that include tickets, something that we have explicitly excluded here. 

5.2 Protocol Composition Logic 

One of the most significant theoretical results in the work on Protocol Com- 
position Logic (PCL) [17] is a strategy for dealing with protocol composition. 
The basic idea is to prove the protocols correct in isolation by constructing a 
correctness proof in the logic. Certain so-called invariants are then identified 
in the correctness proofs, such that protocol correctness follows from these 
invariants only. If these invariants are not violated by the other protocols, it 
is an easy consequence that correctness is retained under composition, since 
correctness follows from the invariants alone. 

In contrast to this very general strategy, our composition theorems identify 
specific classes of protocols that can be composed in certain ways. The advan- 
tage of our approach is that it is highly amenable to automatic verification (as 
demonstrated in Section 4), especially when combined with the trivially ver- 
ifiable strong independence property. In contrast, the full generality of proof 
derivation in PCL seems difficult to automate. 

It is easy to see that our notion of strong independence is a stronger require- 
ment than the invariants used for composition in PCL. Nevertheless, strong 
independence is trivial to verify, hence highly suited for an automatic verifica- 
tion strategy. It is possible that composition theorems similar to ours, based 
on strong independence, could be recovered in the PCL framework. 

The PCL invariant approach can deal with cases that our notion of inde- 
pendence cannot. The reason for this is that independence only considers 
ciphertext terms and their origins, while PCL invariants cover more general 
statements. Conversely, since independence is verified for traces while PCL 
invariants are verified over so-called basic sequences, it is not immediately 
obvious that the PCL approach can deal with every case our independence 
notion can deal with. Investigating this relationship is an interesting topic for 
future research. 

We believe that many ideas and techniques used in PCL can be reused in our 
framework. The techniques used to identify and verify invariants could possibly 
be used to prove independence. Due to the highly manual nature of the PCL 
compositionality strategy, we expect any such work to be complementary to 
the theory developed in this paper, to be used only when automatic techniques 
fail. 

An alternative approach is taken in the PDa tool [3]. In this tool, an ax- 
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iomatic theory is set up to reason about protocol refinement and composition. 
The tool uses ideas from PCL to reason about invariants. The tool can pro- 
vide automatic discharging of simple proofs. However, the user has to provide 
sufficiently strengthened invariants to allow for compositional proofs. The ax- 
iomatic theory does not have a notion of run (or process or thread), similar to 
e.g. BAN logic, and as a result only very weak notions of authentication can 
be considered. 

5.3 Related theoretical results 

The complex problem of compositionality has been approached from a va- 
riety of angles. Many of these approaches are restricted to weak forms of 
authentication, such as [7,8,34]. When only such weaker forms are considered, 
compositionality results can be achieved on the basis of simpler challenge- 
response mechanisms within a protocol, similar to the authentication tests 
from [24]. The existence of these mechanisms in a protocol does not ensure 
synchronization, or even agreement. 

Other approaches have considered secrecy, e.g. [30]. Here a notion of secrecy 
is defined within the context of stream-processing functions. Using the notion 
of an m-secrecy protecting process, a result is given that states that two such 
processes can be safely composed. Furthermore, it is shown that such a process 
remains secrecy-protecting under refinement. Similar to the Strand Spaces 
approach, it is unclear how one can establish that a process (or protocol) 
satisfies the required conditions for the stated theorems. 

In the area of information flow analysis, which is related to the secrecy-only 
approach, there are a number of results and supporting tools, e.g. [21,22,26, 
30,35]. However, because of fundamental differences in the underlying models, 
these results cannot be used for the compositional analysis of security protocols 
such as WiMAX. 

In [10] the observation is made that the correctness of security protocols de- 
pends on the assumptions on the environment. In the wrong environment, or 
in the context of specific protocols, seemingly secure protocols are incorrect. 
The authors give no specific conditions or properties. 

Over the past decades compositional verification has received quite some at- 
tention from the process algebra community and was applied successfully in 
the verification of complex concurrent systems (for an overview of these tech- 
niques, see e.g. [19]). However, these techniques do not seem to carry over 
easily to the process algebras developed especially for security protocols, such 
as the spi calculus [1]. An attempt has been made in [6]. Here, composition- 
ality is interpreted as a congruence property of a bisimulation-like relation 
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over several process operators. Although the authors provide compositional 
rules for (restricted) parallel and action-prefix composition, rules for general 
sequential composition are absent, making it impossible to apply this work to 
e.g. the WiMAX protocol suite. Moreover, the rule for parallel composition 
poses a very strong restriction on the set of processes that may run in parallel 
with any given process. 

Furthermore, the security properties treated are secrecy and weak forms of 
authentication. It is not obvious how general protocol-centric properties and 
especially injectivity can be expressed by means of the bisimulation relation 
provided. Finally, we note that the proposed methodology has severe limita- 
tions with respect to the verification of actual protocols. As an example, the 
authors prove correctness of a version of the Wide Mouthed Frog protocol, 
which is obviously insecure in the standard setting for security protocols. This 
problem is due to the fact that their theory only supports the verification of 
fixed scenarios. 



5.4 Verification of composed security protocols 

In the area of protocol verification, it seems that the first attempt at verifica- 
tion of parallel subprotocols was made in [36], where the interaction between 
subprotocols was investigated manually. 

An attempt at composing security protocol proofs within a theorem-proving 
environment was made in [40]. In this work, the authors construct composi- 
tional proofs for a specific protocol, in order to work towards a general theory. 
The conclusion of the authors is that even for a single protocol, the approach 
requires much manual work, and that scaling problems might cause this ap- 
proach to be infeasible. 

More recently fully automated verification of composed protocols was per- 
formed in [13] employing the same basic framework and tool used here. How- 
ever, this verification, too, has been limited to protocols that are composed in 
parallel. 



6 Conclusion 

We make two significant contributions in this paper. First, we create a frame- 
work for easy verification of a large and useful class of security protocols built 
from smaller subprotocols. Second, we initiate a study of WiMAX, by ap- 
plying our framework to the composition of three protocols from its security 
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sublayer. This is done by first verifying that the three protocols are inde- 
pendent and then analyzing each subprotocol in isolation. The results of this 
analysis are used to deduce properties about the composition of the subproto- 
cols, consisting of the subprotocols running in parallel with suitable transfer of 
information. Consequently, this allows us to derive properties of the composed 
protocol. 

We do not claim that our framework can deal with every possible security 
protocol. One important restriction is the requirement in many theorems that 
subprotocols are independent. This makes it difficult to use our framework for 
analysis of protocols that do not naturally split into independent subprotocols. 
As we have argued, protocol tags are a reasonably cost-effective way to design 
protocols that are amenable to analysis in our framework. WiMAX is just one 
example of protocols in which such techniques are in use today. We believe 
this is a very reasonable approach to future protocol design. 

A significant advantage of our framework is ease of use. If we consider the 
WiMAX analysis, the Scyther tool automatically proves secrecy and synchro- 
nization for the subprotocols. Since session-uniqueness and data agreement 
claims have not yet been implemented in Scyther, a small amount of reason- 
ing is needed to prove that the protocols have these properties in isolation. 
Once the properties are established, however, using the theorems to deduce 
the security properties of the composed protocol is essentially trivial. As the 
WiMAX analysis to some degree shows, it should be possible to verify proto- 
cols without an intimate knowledge of the underlying semantics described in 
Section 2, since a tool like Scyther (once it is suitably extended) can deal with 
the proofs needed at this level. 

An interesting feature of our framework is that the theorem statements are 
not strongly connected to the underlying semantics. They are therefore in a 
sense independent of the semantics. Indeed, we believe the framework could 
be transferred to any other semantics powerful enough to express at least the 
notion of independence and the security properties, and which has a similar 
execution model. 

In general, our theorems are tight in the sense that if any precondition is 
relaxed, the theorem is no longer true. Of course, some theorems could be 
extended in natural ways, and other theorems have many specialized varia- 
tions. For the current work, we believe such extensions would add little value. 
Instead, such results should be proved as needed, slowly increasing the knowl- 
edge about how composition works. 

In this work, we have defined the protocol-centric class of security properties 
and proved many theorems for that class. Likewise, we can define other classes 
of properties, for instance properties that only consider the intruder's memory. 
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Studying such classes of properties and proving theorems about them is an 
interesting future topic. 

Another useful contribution in this paper is our definition of protocol indepen- 
dence. Currently, we have only described one way to achieve independence, 
namely protocol tags. There are several other ways one could imagine achiev- 
ing independence, for instance through some notion of separate key infrastruc- 
tures. One can also imagine other notions of independence that allow general 
theorems to be proved. Such notions would create new protocol design strate- 
gies and allow more protocols to be analyzed. We intend to continue our work 
on this topic. 

The requirement in our semantics that variables only contain nonce run terms 
prevents us from expressing protocols using tickets in the semantics. The re- 
quirement is only essential for Theorem 26. A more significant problem is 
the fact that security properties such as synchronization or agreement do not 
make sense in the context of tickets, since some roles are by definition insen- 
sitive to the content of the tickets. An important topic for future work will be 
to extend our framework with new security properties and new theorems for 
ticket-based security protocols. 

In our framework we discuss how to compose protocols. While sequential com- 
position is the natural notion of protocol composition, there are other possible 
composition operators that are natural to discuss, such as the choice operator 
allowing one out of two protocols to run. Extending our framework with such 
operators and theorems to support reasoning with them is an important future 
topic. 

As we have already noted, the Scyther tool does not have support for every 
security property we have defined, nor for every trace restriction. In the near 
future, we intend to extend Scyther with support for these security properties 
and trace restrictions. A related task is the creation of a new tool to formally 
verify reasoning in our framework. Essentially, this tool will use Scyther as a 
back-end to analyze the subprotocols, then it will verify that every theorem 
application is valid. This will allow automated verification of large protocols. 
As the body of theorems in our framework increases, so will the power of the 
tool when the theorems are added. 

We have analyzed the security requirements of WiMAX and shown that a 
somewhat restricted variant of the protocol satisfies these requirements, all 
by reasoning in our framework and analyzing small subprotocols in isolation. 
We believe our study, though not complete, is a useful first step towards a 
complete analysis of the security requirements of WiMAX, as well as towards 
a verification of the entire protocol suite. In the future, we intend to work out 
a complete analysis of the security sublayer of WiMAX. 
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Today, most new protocols are not verified (in any sense of the word) when 
they are released, for example, as standards. We believe this is because today, 
verification of any sizable protocol is the exclusive province of the few skilled 
specialists and researchers working in the area. An important goal of current 
research is to remedy this problem. As the analysis of the WiMAX protocols 
show, our work is a significant first step towards a framework for security 
protocol analysis (with tool support) that could be used by engineers to verify 
protocols during design, allowing a proper security analysis of the protocol 
before release. 
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